[Python-ideas] More "ensure*" packages

[Wes Turner]

And then for OS system packages:

    whohas "requests"
    whohas "python-requests"

https://github.com/whohas/whohas

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

> "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/f72f8ad2/attachment-0001.html>