Re: [Python-Dev] updating ensurepip to include wheel
On 7 August 2015 at 08:50, Robert Collins wrote: > Certainly the framing of ensurepip as 'this installs pip' is going to > be confusing and misleading if it doesn't install pip the way > get-pip.py (or virtualenv) install pip, leading to confusion such as > that. > > Given the inconsequential impact of installing wheel, I see only harm > in holding it back, and only benefits in adding it. All the harm from > having source builds comes in with setuptools ;). Right, this is the main reason I'm actually *in favour* of adding wheel to the ensurepip bundle upstream - it significantly improves the "out of the box" experience of pyvenv by implicitly caching builds. (I'm also in favour because it will lead to redistributors providing "pip wheel" support by default, and having to make an explicit design decision *not* to provide it if we want to do something different). The only reason I'm asking for a PEP is because I'm confident we're going to want a "support prebuilt wheels only" installation option downstream in the Linux distro world - shipping setuptools by default is a pragmatic concession to practical reality rather than something we *want* to be doing. As such, I do think Robert raises a good point that any new ensurepip option should probably prevent installation of both wheel *and* setuptools, since pip can install from wheel files without setuptools these days. The CLI option name might be something like "--no-build-tools", and could also be added to the public pyvenv and virtualenv interfaces. Downstream in Fedora, now that we have weak dependency support, I'd advocate for switching the python->setuptools dependency over to Recommends, and adding wheel as a Recommends dependency from the start. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
> On Aug 7, 2015, at 3:02 AM, Nick Coghlan wrote: > > On 7 August 2015 at 08:50, Robert Collins wrote: >> Certainly the framing of ensurepip as 'this installs pip' is going to >> be confusing and misleading if it doesn't install pip the way >> get-pip.py (or virtualenv) install pip, leading to confusion such as >> that. >> >> Given the inconsequential impact of installing wheel, I see only harm >> in holding it back, and only benefits in adding it. All the harm from >> having source builds comes in with setuptools ;). > > Right, this is the main reason I'm actually *in favour* of adding > wheel to the ensurepip bundle upstream - it significantly improves the > "out of the box" experience of pyvenv by implicitly caching builds. > (I'm also in favour because it will lead to redistributors providing > "pip wheel" support by default, and having to make an explicit design > decision *not* to provide it if we want to do something different). > > The only reason I'm asking for a PEP is because I'm confident we're > going to want a "support prebuilt wheels only" installation option > downstream in the Linux distro world - shipping setuptools by default > is a pragmatic concession to practical reality rather than something > we *want* to be doing. > > As such, I do think Robert raises a good point that any new ensurepip > option should probably prevent installation of both wheel *and* > setuptools, since pip can install from wheel files without setuptools > these days. The CLI option name might be something like > "--no-build-tools", and could also be added to the public pyvenv and > virtualenv interfaces. > > Downstream in Fedora, now that we have weak dependency support, I'd > advocate for switching the python->setuptools dependency over to > Recommends, and adding wheel as a Recommends dependency from the > start. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia I’m not sure if —no-build-tools make sense, since I plan on removing setuptools from ensurepip completely once pip can implicitly install it. PEP 453 explicitly called out the fact that setuptools was installed as an implementation detail with an eye to remove it in the future. Adding flags that deal with it specifically doesn’t seem like the right path to go down. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
On 7 August 2015 at 17:20, Donald Stufft wrote: > I’m not sure if —no-build-tools make sense, since I plan on removing > setuptools from ensurepip completely once pip can implicitly install it. PEP > 453 explicitly called out the fact that setuptools was installed as an > implementation detail with an eye to remove it in the future. Adding flags > that deal with it specifically doesn’t seem like the right path to go down. I'd be happy for the flag to go the other way, and have to supply "--build-tools" in order to opt in to having ensurepip install setuptools and wheel in addition to pip itself. If we did that, the downstream setup would likely be the even weaker "Suggests" dependency. My use case here is the "offline Python installation" one - having the build tools bundled with CPython and readily available is still useful for cases where you have your own code you want to build, but can't go to the internet to get a build toolchain. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
Le 7 août 2015 00:51, "Robert Collins" a écrit : > So - I was in a talk at PyCon AU about conda[*], and the author > believed they were using the latest pip with all the latest caching > features, but their experience (16 minute installs) wasn't that. If an expert user is unaware of having to explicitly install wheel, what about other users? Packaging is the most hated feature of Python. Please don't add extra pain for purity and make sure that ensurepip installs "pip" and not "slow pip until you install wheel in the venv". To develop on OpenStack, I have more than 20 virtual environment on my PC. I recreate them regulary because I like downgarding or upgrading a package, or edit the code of a package directly in the venv (usually to debug). Since pip7, the creation of venv is much faster. Please don't make pip slower. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
> I'm confident we're > going to want a "support prebuilt wheels only" installation option > downstream in the Linux distro world - Interesting-- so move to a Python specific binary distribution option -- rather than using rm or deb packages? Doesn't lead to a dependency heck? I.e no way to express non-python dependencies? And while we are moving forward, can we please deprecate dependency management and installation from setuptools? Is there a philosophy of intended separation of concerns articulated somewhere? -Chris > shipping setuptools by default > is a pragmatic concession to practical reality rather than something > we *want* to be doing. > > As such, I do think Robert raises a good point that any new ensurepip > option should probably prevent installation of both wheel *and* > setuptools, since pip can install from wheel files without setuptools > these days. The CLI option name might be something like > "--no-build-tools", and could also be added to the public pyvenv and > virtualenv interfaces. > > Downstream in Fedora, now that we have weak dependency support, I'd > advocate for switching the python->setuptools dependency over to > Recommends, and adding wheel as a Recommends dependency from the > start. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
>Please don't add extra pain for purity and >make sure that ensurepip installs "pip" and >not "slow pip until you install wheel in the venv". This is a really good point -- other than purity, what is the downside? Arguably, the only reason setuptools, pip, and wheel are not in the standard library are because the need a more rapid development/release cycle. Ensurepip is the way to get the best of both worlds -- why not make it complete? -Chris ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-07-31 - 2015-08-07) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4992 (+31) closed 31595 (+32) total 36587 (+63) Open issues with patches: 2245 Issues opened (55) == #24759: Idle: add ttk widgets as an option http://bugs.python.org/issue24759 reopened by terry.reedy #24764: cgi.FieldStorage can't parse multipart part headers with Conte http://bugs.python.org/issue24764 opened by Peter Landry #24765: Move .idlerc to %APPDATA%\IDLE on Windows http://bugs.python.org/issue24765 opened by jan parowka #24766: Subclass of property doesn't preserve instance __doc__ when us http://bugs.python.org/issue24766 opened by erik.bray #24767: can concurrent.futures len(Executor) return the number of task http://bugs.python.org/issue24767 opened by Pat Riehecky #24769: Interpreter doesn't start when dynamic loading is disabled http://bugs.python.org/issue24769 opened by Jeffrey.Armstrong #24770: Py_Finalize not cleaning up all threads http://bugs.python.org/issue24770 opened by Alex Budovski #24772: Smaller viewport shifts the "expand left menu" character into http://bugs.python.org/issue24772 opened by karlcow #24773: Add local time disambiguation flag to datetime http://bugs.python.org/issue24773 opened by belopolsky #24774: inconsistency in http.server.test http://bugs.python.org/issue24774 opened by wdv4758h #24775: Python client failing to connect to server but completing as i http://bugs.python.org/issue24775 opened by Seán Kelleher #24776: Improve Fonts/Tabs UX for IDLE http://bugs.python.org/issue24776 opened by rhettinger #24778: mailcap.findmatch: document shell command Injection danger in http://bugs.python.org/issue24778 opened by TheRegRunner #24779: Python/ast.c: decode_unicode is never called with rawmode=True http://bugs.python.org/issue24779 opened by eric.smith #24780: unittest assertEqual difference output foiled by newlines http://bugs.python.org/issue24780 opened by chris.jerdonek #24781: Improve UX of IDLE Highlighting configuration tab http://bugs.python.org/issue24781 opened by markroseman #24782: Merge 'configure extensions' into main IDLE config dialog http://bugs.python.org/issue24782 opened by markroseman #24783: Import Error (undefined symbol: PyFloat_Type) when Importing m http://bugs.python.org/issue24783 opened by david-narvaez #24784: Build fails --without-threads http://bugs.python.org/issue24784 opened by louis.dassy #24786: Changes in the devguide repository are not published online in http://bugs.python.org/issue24786 opened by jcea #24787: csv.Sniffer guesses "M" instead of \t or , as the delimiter http://bugs.python.org/issue24787 opened by Tiago Wright #24788: HTTPException is derived from Exception instead of IOError http://bugs.python.org/issue24788 opened by Pastafarianist #24789: ctypes doc string http://bugs.python.org/issue24789 opened by LambertDW #24790: Idle: improve stack viewer http://bugs.python.org/issue24790 opened by terry.reedy #24792: zipimporter masks import errors http://bugs.python.org/issue24792 opened by Amund Hov #24794: PyZipFile mixes compiled files from different python versions. http://bugs.python.org/issue24794 opened by Amund Hov #24795: Make event loops with statement context managers http://bugs.python.org/issue24795 opened by Mathias Fröjdman #24796: Deleting names referencing from enclosed and enclosing scopes http://bugs.python.org/issue24796 opened by ncoghlan #24798: _msvccompiler.py doesn't properly support manifests http://bugs.python.org/issue24798 opened by gladman #24799: IDLE should detect changes to open files by other processes http://bugs.python.org/issue24799 opened by Al.Sweigart #24800: exec docs should note that the no argument form in a local sco http://bugs.python.org/issue24800 opened by Peter Eastman #24801: right-mouse click in IDLE on Mac doesn't work http://bugs.python.org/issue24801 opened by markroseman #24802: PyFloat_FromString Buffer Over-read http://bugs.python.org/issue24802 opened by JohnLeitch #24803: PyNumber_Long Buffer Over-read.patch http://bugs.python.org/issue24803 opened by JohnLeitch #24805: Python installer having problem in installing Python for all u http://bugs.python.org/issue24805 opened by Debarshi.Goswami #24806: Inheriting from NoneType does not fail consistently http://bugs.python.org/issue24806 opened by brechtm #24807: compileall can cause Python installation to fail http://bugs.python.org/issue24807 opened by Jon Ribbens #24808: PyTypeObject fields have incorrectly documented types http://bugs.python.org/issue24808 opened by Joseph Weston #24809: Add getprotobynumber to socket module http://bugs.python.org/issue24809 opened by wbooth #24810: UX mode for IDLE targeted to 'new learners' http://bugs.python.org/issue24810 opened by mar
Re: [Python-Dev] updating ensurepip to include wheel
> On Aug 7, 2015, at 11:13 AM, Chris Barker - NOAA Federal > wrote: > >> Please don't add extra pain for purity and >> make sure that ensurepip installs "pip" and >> not "slow pip until you install wheel in the venv". > > > This is a really good point -- other than purity, what is the downside? > > Arguably, the only reason setuptools, pip, and wheel are not in the > standard library are because the need a more rapid development/release > cycle. > > Ensurepip is the way to get the best of both worlds -- why not make it > complete? > So my opinion is basically that in a vacuum I would absolutely add wheel to ensurepip (and I did add wheel to get-pip.py and to virtualenv). However, this does not exist in a vacuum and there is still animosity about PEP 453 and downstream’s are still trying to figure out how they are going to handle it for real. During the 3.4 release there were downstream redisttibutors who completely removed ensurepip and were talking about possibly removing pip entirely from their archives. So my hesitation is basically that I consider is a short (or medium) term need until pip can implicitly install wheel and setuptools as part of the build process for a particular project and I worry that it will reopen some wounds and cause more strife. I do however think it would make ensurepip itself better, so I’m not dead set against it, mostly just worried about ramifications. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP-498: Literal String Formatting
Following a long discussion on python-ideas, I've posted my draft of
PEP-498. It describes the "f-string" approach that was the subject of
the "Briefer string format" thread. I'm open to a better title than
"Literal String Formatting".
I need to add some text to the discussion section, but I think it's in
reasonable shape. I have a fully working implementation that I'll get
around to posting somewhere this weekend.
>>> def how_awesome(): return 'very'
...
>>> f'f-strings are {how_awesome()} awesome!'
'f-strings are very awesome!'
I'm open to any suggestions to improve the PEP. Thanks for your feedback.
--
Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
On 8 August 2015 at 02:12, Donald Stufft wrote: > >> On Aug 7, 2015, at 11:13 AM, Chris Barker - NOAA Federal >> wrote: >> >>> Please don't add extra pain for purity and >>> make sure that ensurepip installs "pip" and >>> not "slow pip until you install wheel in the venv". >> >> >> This is a really good point -- other than purity, what is the downside? >> >> Arguably, the only reason setuptools, pip, and wheel are not in the >> standard library are because the need a more rapid development/release >> cycle. >> >> Ensurepip is the way to get the best of both worlds -- why not make it >> complete? >> > > So my opinion is basically that in a vacuum I would absolutely add wheel to > ensurepip (and I did add wheel to get-pip.py and to virtualenv). However, > this does not exist in a vacuum and there is still animosity about PEP 453 > and downstream’s are still trying to figure out how they are going to handle > it for real. During the 3.4 release there were downstream redisttibutors who > completely removed ensurepip and were talking about possibly removing pip > entirely from their archives. [I'm wearing my professional Fedora Environments & Stack WG and RHEL Developer Experience hats in this post, moreso than my CPython core developer one] It seems to me that most modern open source developers (especially those using dynamic languages) perceive Linux distros more as impediments to be worked around, rather than as allies to collaborate with, and that's *our* UX issue to figure out downstream (hence design concepts like https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement and https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessRedesign in the Fedora space) It's not CPython's problem to resolve, and it's only CPython's responsibility to work around to the extent that it makes things easier for *end users* developing in Python. If a distro is being unreasonably intransigent about developer experience concerns, then that's the distro's problem, and we can advise people to download and use a cross-platform distro like ActivePython, EPD/Canopy or Anaconda instead of the system Python. > So my hesitation is basically that I consider is a short (or medium) term > need until pip can implicitly install wheel and setuptools as part of the > build process for a particular project and I worry that it will reopen some > wounds and cause more strife. I don't believe it's a good idea to avoid strife for the sake of avoiding strife - many Linux distros are in the wrong here, and we need to get with the program in suitably meeting the needs of open source developers, not just folks running Linux on production servers. Fedora started that process with the launch of the Fedora.next initiatives a couple of years ago, but there's still a lot of work to be done in retooling our online and desktop experience to make it more developer friendly. > I do however think it would make ensurepip itself better, so I’m not dead set > against it, mostly just worried about ramifications. I'd advise against letting concerns about Linux distro politics hold you back from making ensurepip as good as you can make it - if nothing else, the developer experience folks at commercial Linux vendors are specifically paid to advocate for the interests of software developers when it comes to the Linux user experience (that's part of my own day job in the Fedora/RHEL/CentOS case - I moved over to the software management team in RHEL Developer Experience at the start of June). That means that while I will have some *requests* to make certain things easier downstream (like going through the PEP process to figure out an upstream supported way to omit the build-only dependencies when running ensurepip), I also wholeheartedly endorse the idea of having the default upstream behaviour focus on making the initial experience for folks downloading Windows or Mac OS X binaries from python.org as compelling as we can make it. python-dev needs to put the needs of Python first, and those of Linux second. This does mean that any Linux distro that can't figure out how to provide a better open source developer experience for Pythonistas than Windows or Mac OS X is at risk of falling by the wayside in the Python community, but if those of us that care specifically about the viability of desktop Linux as a platform for open source development stand by and let that happen, then we'll *deserve* the consequences. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
