[Python-ideas] More "ensure*" packages

[Wes Turner]

"The SciPy Stack"
http://www.scipy.org/install.html
http://www.scipy.org/stackspec.html
https://westurner.org/tools/#scipy-stack


http://docs.continuum.io/anaconda/pkg-docs

tk <http://www.tcl.tk/> Linux Mac8.5.18
requests <http://docs.python-requests.org/en/latest/index.html>2.7.0

https://www.enthought.com/products/canopy/package-index/

requests <http://docs.python-requests.org/en/latest/>2.7.0



On Thu, Aug 13, 2015 at 6:03 PM, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Thu, Aug 13, 2015 at 4:50 PM, Donald Stufft <donald at stufft.io> wrote:
>
>> On August 13, 2015 at 5:29:15 PM, Steve Dower (steve.dower at python.org)
>> wrote:
>> >
>> > It's already a fairly crowded marketplace, at least on Windows.
>> > Anaconda, Canopy, WinPython, Pythonxy and Portable Python all come to
>> > mind, but none of them have reliably replaced the official Python
>> > installer. In large part, I suspect this is because they do too much -
>> > most include the scipy stack and at least one (typically 4-5) editors.
>>
>> I think that’s also discounting the *huge* benefit of something being
>> offered as the official Python thing. I think a lot of people are hesitant
>> to install those other things because they come someone else, or they
>> aren’t even aware of them because they searched for Python on google and
>> got the official installer.
>>
>> >
>> > What might be interesting is if we installed the meta-package into the
>> > Lib directory rather than Lib/site-packages. That also opens up the
>> > possibility of removing old/deprecated modules from the stdlib but
>> > having an install option to restore them. Which helps break up the
>> > stdlib a bit and make the core Python install lighter, but still isn't
>> > really suitable for something like requests.
>>
>> Right, I don’t think it’s suitable at all to install something that is
>> typically installed from PyPI into anything other than Lib/site-packages.
>>
>> >
>> > I also don't see any real gain in making it a separate thing from the
>> > main installer unless you're planning 10+ packages to be in there. I
>> > would expect an incredibly small amount of packages to be available -
>> > those with no significant competitors, extremely broad uses, and
>> > completely portable.
>> >
>>
>> Can we release new, different, installers for say, a hypothetical 3.5.0
>> without cutting a new release of 3.5.0 that include updated versions of the
>> bundled software? If so, how will people know they are using the latest
>> version of that installer? I know that requests will not be very happy
>> being bundled like that if getting a new version is tied to a new version
>> of Python being released.
>>
>> This is one of the primary benefits of a separate installer, the
>> installer (really the set of things that get installed) gets a version
>> number. You can release it independently of a Python release, so if
>> requests has a security issue then you can just roll out a new version of
>> the platform installer without that affecting Python at all.
>>
>> Another major benefit of a separate installer that layers ontop of Python
>> is reducing (or eliminating) the friction it will cause with downstream
>> redistributors. The “sort of stdlib, sort of not” status of pip is weird
>> and has caused a bit of a problem. I’m still dealing with the fallout of
>> that, and while we had to do it that way in order for it to work inside of
>> virtual environments, I don’t think we need to do this that way.
>>
>> I also think the separation just makes way more sense, when you have
>> ensure* it means that things like python-pip depend on Python, but then
>> Python also depends on them. I don’t think that Python the runtime needs to
>> depends on requests and I think that doing that is going the wrong way.
>> What this really is, is just a collection of preinstalled packages, so
>> treating it like that seems like a better option.
>>
>
> Challenges
>
> - [ ] repeatable build scripts (to ensure reproducible environments)
>   - tox
>   - Pip
>   - Dockerfiles (for specific operating system)
>   - Installer script / PACKAGES (to be installed/called be each Dockerfile)
>   - What about windows?
> - [ ] installing third party packages
>       (python -m ensurepip; pip install -U pip; pip install -r
> requirements.txt)
>
> If you're suggesting that Python should test and maintain a distribution
> of specific PyPi packages,
> which commands do I need to add to my Dockerfiles, and OSX/Windows?
>
>  -
> https://github.com/ipython/ipython/wiki/Install:-Docker#anaconda--ipython-configurations
>  - https://www.python.org/dev/buildbot/
>  - https://wiki.python.org/moin/BuildbotOnWindows (this is probably out
> of date; download and build which packages every time?)
>
>
>>
>> -----------------
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150813/5ab4b24a/attachment.html>