Open Source SQLPS

  • Comments posted to this topic are about the item Open Source SQLPS

  • One of the key things for an open-source product is to have a strong gatekeeper.

    Linus Thorvald fulfilled the role fantastically for Linux, Shay Banmon did the same for Elastic Search.

    Provided Microsoft fulfill the role of Gatekeeper then I say go for it.

  • I would be very pleased if Microsoft did this.

    412-977-3526 call/text

  • David.Poole (3/11/2016)


    One of the key things for an open-source product is to have a strong gatekeeper.

    Linus Thorvald fulfilled the role fantastically for Linux, Shay Banmon did the same for Elastic Search.

    Provided Microsoft fulfill the role of Gatekeeper then I say go for it.

    This is what I was going to say.

    I am happy for others to have their own fork but, I suspect, for most of us we would want a stable trunk that is the officially distributed for SQL Server release that is moderately paced in changes, not tied to SQL Server's release cycle and allows for global proposed enhancements.

    I am happy for Microsoft to maintain focus on the core product which is, by its very definition, central to the platform and importantly to their income.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • SQLPSX (SQL PowerShell Extensions) is a ready alternative. Open source at http://sqlpsx.codeplex.com/.

    Active development seems to have stopped a couple of years ago but it is open source under the MIT license.

  • (sigh!) Once again, I find myself wishing PS was still-born. Microsoft already had a viable alternative in IronPython (first appeared September 5, 2006) which is a far more capable language (and without C-style braces for control structures!). In fact, today you can easily write more elegant code in IronPython to access SMO, for example.

    Considering that Apple and most (all?) Linux distros use Python for system management, I never could see why it wasn't "good enough" for Microsoft. Ironically, now that SQL Server 2016 is going to be available on Linux, the logical next step is to use Python for scripting there rather than porting PS to Linux.

    Gerald Britton, Pluralsight courses

  • I am a long-time Python fan and user but the comparison is apples and oranges.

    If you try to use PS in the same ways you would use Python, or Ruby, or Perl, or whatever, then it is, indeed, clunky.

    But that misses the point entirely. You have to write PowerShell as PowerShell, not as some other language.

    True objects in pipelines is a complete game-changer!

  • n.arley.dealey (3/11/2016)


    I am a long-time Python fan and user but the comparison is apples and oranges.

    If you try to use PS in the same ways you would use Python, or Ruby, or Perl, or whatever, then it is, indeed, clunky.

    But that misses the point entirely. You have to write PowerShell as PowerShell, not as some other language.

    True objects in pipelines is a complete game-changer!

    Well, I'm not saying use PS the way you use Python, I'm saying PS was unnecessary from the get-go when a much-more capable language was ready.

    FWIW I find little difficulty in either:

    some-cmdlet args | some_other_cmdlet

    or

    for x in some_iterator(args):

    some_other_iterator(x)

    Combined with the full power of Python iterators, PS simply looks immature.

    Gerald Britton, Pluralsight courses

  • I tend to agree with g.britton. Python would have been a better choices, IMHO, for lots of the admin stuff. If they'd hooked this into the .NET namespaces and objects, it would work well.

    Imagine the generators we could build with Python and various AD/.NET objects...

  • Python...another technology on the list rarely visited.

    Too much to learn and evaluate. Too little time.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Steve Jones - SSC Editor (3/11/2016)


    I tend to agree with g.britton. Python would have been a better choices, IMHO, for lots of the admin stuff. If they'd hooked this into the .NET namespaces and objects, it would work well.

    Imagine the generators we could build with Python and various AD/.NET objects...

    Fwiw ironpython *is*.net. I've done some smo stuff with it

    Gerald Britton, Pluralsight courses

  • robert.sterbal 56890 (3/11/2016)


    I would be very pleased if Microsoft did this.

    Me too.

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply