Re: [Python-Dev] VS 2010 compiler
On 30 September 2015 at 01:31, Chris Barker - NOAA Federal wrote: > It may be -- I've still have to test. Neither Windows nor py3 are my > primary production versions. Part of the problem here is that people put up postings saying "do this" having checked that it works for them, and then others say "but it doesn't work", without giving any information as to why or providing any means to improve the instructions. I'm not suggesting here that you're going to do this - but those instructions are in essence the "official" (not well documented, conceded) advice at present, and they have been tested by a number of people for whom they work. They have also been reported to fail, but (as noted above) never in a way that allows us to improve them :-( They will remain the official advice, I suspect, until we get better feedback. > But the last time I tried the SDK approach was for py2.7 on Win64, and > it was both a pain, and impossible to set up to "just work" in my > highly secure environment. Well, I'd need more explanation of the issues. Was "install the SDK" a problem? Or was "set the environment variable DISTUTILS_USE_SDK"? Or did the instructions to do those two things not work? (I appreciate we're talking about 2 different things here, and I think Python 3 is a much less painful case than 2.7 on win64 was prior to the Visual C for Python 2.7 package). I suspect (from your mention of a highly secure environment) that installing the SDK was the main pain point. That's been the case for a number of people, I believe. But I don't think advice on how to install the Windows SDK in various environments is something we'd want to maintain in the Python documentation... This of course is another aspect of the problem - the official answer is "use a supported version of Windows, ensure you have the necessary permissions to install the needed software, and off you go". But in real life people want to build on an old laptop they had lying around, or on a VM they created on Linux, or on their Linux box using Wine, or on the box they use for a load of other development that has more SDKs than you want to imagine already installed, some of which got broken in the past, ... Or they need to use mingw, because a key library can't be compiled with Visual Studio. These are all real problems, and the people fighting them are doing a huge amount of good work building binary distributions for the community. They document what they are doing to solve their issues and those documents show up on Google, causing people who just want to build a simple extension to find them and get hopelessly confused. > So at best, it needs some serious documentation. And no, it shouldn't > be just a blog post somewhere (unless maybe Steve Dowers's blog). OK, without wishing to minimise what I fully agree is a serious problem, at a very high level the instructions are: For Python 2.7: 1. Install "Visual C++ Compiler Package for Python 2.7" 2. Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case). 3. Done. For Python 3.4 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) 2. Work from an SDK command prompt (with the environment variables set, and the SDK on PATH). 3. Set DISTUTILS_USE_SDK=1 4. Done. For Python 3.5 1. Install Visual Studio 2015 Community Edition (or any later version, when these are released). 2. Done. > Thus whole issue has been dogging python on windows for many years -- > it never has been easy to find out what to do. > > In fact, there are all sorts of Blog posts out there, with various > levels of out of date, conflicting, or just plain wrong advice. And this is why it's hard to fix the problem - people don't look at the documentation, they don't try to find "official" advice, they simply google and get a load of confusing advice. See above as to why some of those documents are there, and are more complex than the average user needs. > A definitive version in the official docs would be a very good thing. Well, I'd happily put the above instructions in the packaging user guide (packaging.python.org). Would that be sufficient for you? Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
TL;DR -- yes, documenting this in packaging.python.org would be great! > Part of the problem here is that people put up postings saying "do > this" having checked that it works for them, and then others say "but > it doesn't work", without giving any information as to why or > providing any means to improve the instructions. Exactly. Which is why a Blog post is not the answer. If I find a blog post, I have no idea how well vetted and tested it is. If you look at the history of the Cython Wiki page about this, it becomes very clear how much confusion there is. (Though I think it's in pretty god shape now-- wikis have the advantage of being able to evolve and getter better). > I'm not suggesting here that you're going to do this - Absolutely not -- I would not post anything anywhere without review -- this's kind of the point. If I find it in an official source, I know it's been reviewed. > us to improve them :-( > They will remain the official advice, I suspect, until we get better > feedback. Which is my point -- how do I currently know what the official advise is? (Yes, I know now -- thanks!) But posting to python-dev is exactly the wrong way to find out! >> But the last time I tried the SDK approach was for py2.7 on Win64, and >> it was both a pain, and impossible to set up to "just work" in my >> highly secure environment. > > Well, I'd need more explanation of the issues. Was "install the SDK" a > problem? Or was "set the environment variable DISTUTILS_USE_SDK"? Or > did the instructions to do those two things not work? The issue was not having permissions to alter the registry the way we wanted. But again, I'll need to do some proper testing with up to date everything and see what happens. > I think Python 3 is a > much less painful case than 2.7 on win64 was prior to the Visual C for > Python 2.7 package). Good to know. > But I don't think advice on how to > install the Windows SDK in various environments is something we'd want > to maintain in the Python documentation... Agreed -- if you can't install it you can't install it. And if it can't be installed in user-space, that's between MS and your sysadmins... > This of course is another aspect of the problem - the official answer > is "use a supported version of Windows, ensure you have the necessary > permissions to install the needed software, and off you go". Well, I for one think that's fine. Supporting open source software on a closed-source OS is going to have these pain points. > OK, without wishing to minimise what I fully agree is a serious > problem, at a very high level the instructions are: > > For Python 2.7: > > 1. Install "Visual C++ Compiler Package for Python 2.7" > 2. Use (a recent version of) setuptools in your setup.py (pip will do > this for you, in any case). > 3. Done. That new MS installer is really really great. > For Python 3.4 > > 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) > 2. Work from an SDK command prompt (with the environment variables > set, and the SDK on PATH). > 3. Set DISTUTILS_USE_SDK=1 > 4. Done. This, unfortunately is non-trivial, and really a pain if you want to automate builds. Apparently, conda-build has got this automated under the hood. Maybe that could be kludge do into setuptools? > - people don't look at > the documentation, they don't try to find "official" advice, they > simply google and get a load of confusing advice. Well, yes, but when there is no official advice, looking for it doesn't help I, for one, have looked for docs and official advise over and over again for many years ( back when kept trying to remember if py2.6 was built with VS2003 or VS2008, or ?? > Well, I'd happily put the above instructions in the packaging user > guide (packaging.python.org). Would that be sufficient for you? That would be great, thanks! An "official" source, but easier to update that the regular docs. Thanks, -Chris ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
On 30 September 2015 at 16:57, Chris Barker - NOAA Federal wrote: >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) >> 2. Work from an SDK command prompt (with the environment variables >> set, and the SDK on PATH). >> 3. Set DISTUTILS_USE_SDK=1 >> 4. Done. > > This, unfortunately is non-trivial, and really a pain if you want to > automate builds. Please clarify. What is non-trivial? Installing the SDK? I know, but we said that's out of scope. Using an SDK command prompt? It is, sort of, particularly if (like me) you use powershell. But again, not our issue. I assume setting the environment variable isn't an issue - you can do it for the session rather than globally, so even restrictive permissions aren't a problem. I appreciate you mightn't be intending this as criticism of the instructions, but many people do criticise in exactly this sort of way. Unix developers, in particular, who have limited Windows knowledge, find this level of instruction really frustrating to deal with. That's not a complaint - I have *huge* appreciation for non-Windows users who bother to make builds for Windows users - but it is an acknowledgement that often the audience for this sort of instruction are stumped by Microsoft's less than intuitive install processes... For context, installing mingw is just as messy, complicated and error prone (I speak from experience :-)) so it's unfair to complain that the above is a non-trivial pain. I know of no install option that's *less* straightforward than this (except of course for "install any version of Visual Studio 2010, even the free ones" - if you have access to those, use them!) For automation, why not use Appveyor? See https://packaging.python.org/en/latest/appveyor/ Unless you meant setting up a local build machine. If you want a simple "install a Python build environment" process, you could look at https://github.com/pfmoore/pybuild - I haven't used it in a while (as it's of no relevance to me, because I have VS2010) but it does work. I never publicised or distributed it, because I got too much pushback in terms of "but it doesn't work right on my system" (typically because the system in question usually *wasn't* a clean build of Windows) that I didn't have time or energy to address. But if it works for you, go for it. I'll push an addition to packaging.python.org, probably tomorrow. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
Concerning the claims that mingw is difficult: The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, that is in development. It is designed for simple use and for much better compatibility to the standard MSVC python builds. It should work out of the box, as long as the \Scripts folder is in the PATH. It is not 'officially' released and announced, due to the fact that some features are missing, the documentation has to be written and the build scripts for the toolchain are not (yet) published. Install a prerelease of mingwpy with pip: pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy or with conda: (thanks to omnia-md) conda install -c https://conda.anaconda.org/omnia mingwpy and use it at usual with pip install or python setup.py You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy if you have an MSVC compiler installed: [config] compiler=mingw32 [build] compiler=mingw32 [build_ext] compiler=mingw32 Or you install the latest portable winpython distribution https://winpython.github.io that contains the toolchain as well and works out of the box. Future releases of mingwpy will be deployed on Pypi. That has to be said: the main emphasis of the toolchain is building python binary extension (C, C++, GFORTRAN) on windows, not building python itself. Carl 2015-09-30 21:15 GMT+02:00 Paul Moore : > On 30 September 2015 at 16:57, Chris Barker - NOAA Federal > wrote: > >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) > >> 2. Work from an SDK command prompt (with the environment variables > >> set, and the SDK on PATH). > >> 3. Set DISTUTILS_USE_SDK=1 > >> 4. Done. > > > > This, unfortunately is non-trivial, and really a pain if you want to > > automate builds. > > Please clarify. What is non-trivial? Installing the SDK? I know, but > we said that's out of scope. Using an SDK command prompt? It is, sort > of, particularly if (like me) you use powershell. But again, not our > issue. I assume setting the environment variable isn't an issue - you > can do it for the session rather than globally, so even restrictive > permissions aren't a problem. > > I appreciate you mightn't be intending this as criticism of the > instructions, but many people do criticise in exactly this sort of > way. Unix developers, in particular, who have limited Windows > knowledge, find this level of instruction really frustrating to deal > with. That's not a complaint - I have *huge* appreciation for > non-Windows users who bother to make builds for Windows users - but it > is an acknowledgement that often the audience for this sort of > instruction are stumped by Microsoft's less than intuitive install > processes... > > For context, installing mingw is just as messy, complicated and error > prone (I speak from experience :-)) so it's unfair to complain that > the above is a non-trivial pain. I know of no install option that's > *less* straightforward than this (except of course for "install any > version of Visual Studio 2010, even the free ones" - if you have > access to those, use them!) > > For automation, why not use Appveyor? See > https://packaging.python.org/en/latest/appveyor/ Unless you meant > setting up a local build machine. If you want a simple "install a > Python build environment" process, you could look at > https://github.com/pfmoore/pybuild - I haven't used it in a while (as > it's of no relevance to me, because I have VS2010) but it does work. I > never publicised or distributed it, because I got too much pushback in > terms of "but it doesn't work right on my system" (typically because > the system in question usually *wasn't* a clean build of Windows) that > I didn't have time or energy to address. But if it works for you, go > for it. > > I'll push an addition to packaging.python.org, probably tomorrow. > > Paul > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
Hi Carl, Looks promising. Any chance the effort would consider cross-compiling (from Linux) as a possible objective ? Best, Laurent On Wed, Sep 30, 2015, 3:58 PM Carl Kleffner wrote: > Concerning the claims that mingw is difficult: > > The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, > that is in development. It is designed for simple use and for much better > compatibility to the standard MSVC python builds. It should work out of the > box, as long as the \Scripts folder is in the PATH. > > It is not 'officially' released and announced, due to the fact that some > features are missing, the documentation has to be written and the build > scripts for the toolchain are not (yet) published. > > Install a prerelease of mingwpy with pip: > > pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy > > or with conda: (thanks to omnia-md) > > conda install -c https://conda.anaconda.org/omnia mingwpy > > and use it at usual with pip install or python setup.py > > You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy if > you have an MSVC compiler installed: > > [config] > compiler=mingw32 > [build] > compiler=mingw32 > [build_ext] > compiler=mingw32 > > Or you install the latest portable winpython distribution > https://winpython.github.io that contains the toolchain as well and works > out of the box. > > Future releases of mingwpy will be deployed on Pypi. > > That has to be said: the main emphasis of the toolchain is building python > binary extension (C, C++, GFORTRAN) on windows, not building python itself. > > Carl > > 2015-09-30 21:15 GMT+02:00 Paul Moore : > >> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal >> wrote: >> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) >> >> 2. Work from an SDK command prompt (with the environment variables >> >> set, and the SDK on PATH). >> >> 3. Set DISTUTILS_USE_SDK=1 >> >> 4. Done. >> > >> > This, unfortunately is non-trivial, and really a pain if you want to >> > automate builds. >> >> Please clarify. What is non-trivial? Installing the SDK? I know, but >> we said that's out of scope. Using an SDK command prompt? It is, sort >> of, particularly if (like me) you use powershell. But again, not our >> issue. I assume setting the environment variable isn't an issue - you >> can do it for the session rather than globally, so even restrictive >> permissions aren't a problem. >> >> I appreciate you mightn't be intending this as criticism of the >> instructions, but many people do criticise in exactly this sort of >> way. Unix developers, in particular, who have limited Windows >> knowledge, find this level of instruction really frustrating to deal >> with. That's not a complaint - I have *huge* appreciation for >> non-Windows users who bother to make builds for Windows users - but it >> is an acknowledgement that often the audience for this sort of >> instruction are stumped by Microsoft's less than intuitive install >> processes... >> >> For context, installing mingw is just as messy, complicated and error >> prone (I speak from experience :-)) so it's unfair to complain that >> the above is a non-trivial pain. I know of no install option that's >> *less* straightforward than this (except of course for "install any >> version of Visual Studio 2010, even the free ones" - if you have >> access to those, use them!) >> >> For automation, why not use Appveyor? See >> https://packaging.python.org/en/latest/appveyor/ Unless you meant >> setting up a local build machine. If you want a simple "install a >> Python build environment" process, you could look at >> https://github.com/pfmoore/pybuild - I haven't used it in a while (as >> it's of no relevance to me, because I have VS2010) but it does work. I >> never publicised or distributed it, because I got too much pushback in >> terms of "but it doesn't work right on my system" (typically because >> the system in question usually *wasn't* a clean build of Windows) that >> I didn't have time or energy to address. But if it works for you, go >> for it. >> >> I'll push an addition to packaging.python.org, probably tomorrow. >> >> Paul >> > ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com >> > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
It should be possible with Wine. Am 30.09.2015 22:50 schrieb "Laurent Gautier" : > Hi Carl, > > Looks promising. > > Any chance the effort would consider cross-compiling (from Linux) as a > possible objective ? > > Best, > > Laurent > > On Wed, Sep 30, 2015, 3:58 PM Carl Kleffner wrote: > >> Concerning the claims that mingw is difficult: >> >> The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, >> that is in development. It is designed for simple use and for much better >> compatibility to the standard MSVC python builds. It should work out of the >> box, as long as the \Scripts folder is in the PATH. >> >> It is not 'officially' released and announced, due to the fact that some >> features are missing, the documentation has to be written and the build >> scripts for the toolchain are not (yet) published. >> >> Install a prerelease of mingwpy with pip: >> >> pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy >> >> or with conda: (thanks to omnia-md) >> >> conda install -c https://conda.anaconda.org/omnia mingwpy >> >> and use it at usual with pip install or python setup.py >> >> You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy >> if you have an MSVC compiler installed: >> >> [config] >> compiler=mingw32 >> [build] >> compiler=mingw32 >> [build_ext] >> compiler=mingw32 >> >> Or you install the latest portable winpython distribution >> https://winpython.github.io that contains the toolchain as well and >> works out of the box. >> >> Future releases of mingwpy will be deployed on Pypi. >> >> That has to be said: the main emphasis of the toolchain is building >> python binary extension (C, C++, GFORTRAN) on windows, not building python >> itself. >> >> Carl >> >> 2015-09-30 21:15 GMT+02:00 Paul Moore : >> >>> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal >>> wrote: >>> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) >>> >> 2. Work from an SDK command prompt (with the environment variables >>> >> set, and the SDK on PATH). >>> >> 3. Set DISTUTILS_USE_SDK=1 >>> >> 4. Done. >>> > >>> > This, unfortunately is non-trivial, and really a pain if you want to >>> > automate builds. >>> >>> Please clarify. What is non-trivial? Installing the SDK? I know, but >>> we said that's out of scope. Using an SDK command prompt? It is, sort >>> of, particularly if (like me) you use powershell. But again, not our >>> issue. I assume setting the environment variable isn't an issue - you >>> can do it for the session rather than globally, so even restrictive >>> permissions aren't a problem. >>> >>> I appreciate you mightn't be intending this as criticism of the >>> instructions, but many people do criticise in exactly this sort of >>> way. Unix developers, in particular, who have limited Windows >>> knowledge, find this level of instruction really frustrating to deal >>> with. That's not a complaint - I have *huge* appreciation for >>> non-Windows users who bother to make builds for Windows users - but it >>> is an acknowledgement that often the audience for this sort of >>> instruction are stumped by Microsoft's less than intuitive install >>> processes... >>> >>> For context, installing mingw is just as messy, complicated and error >>> prone (I speak from experience :-)) so it's unfair to complain that >>> the above is a non-trivial pain. I know of no install option that's >>> *less* straightforward than this (except of course for "install any >>> version of Visual Studio 2010, even the free ones" - if you have >>> access to those, use them!) >>> >>> For automation, why not use Appveyor? See >>> https://packaging.python.org/en/latest/appveyor/ Unless you meant >>> setting up a local build machine. If you want a simple "install a >>> Python build environment" process, you could look at >>> https://github.com/pfmoore/pybuild - I haven't used it in a while (as >>> it's of no relevance to me, because I have VS2010) but it does work. I >>> never publicised or distributed it, because I got too much pushback in >>> terms of "but it doesn't work right on my system" (typically because >>> the system in question usually *wasn't* a clean build of Windows) that >>> I didn't have time or energy to address. But if it works for you, go >>> for it. >>> >>> I'll push an addition to packaging.python.org, probably tomorrow. >>> >>> Paul >>> >> ___ >>> Python-Dev mailing list >>> Python-Dev@python.org >>> https://mail.python.org/mailman/listinfo/python-dev >>> >> Unsubscribe: >>> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com >>> >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com >> > ___ Python-Dev mailing list Python-Dev@python.org https://m
[Python-Dev] PEP acceptance and SIGs
It has been my understanding that some PEPs may be discussed on specialized mailings lists, but a notice would be given on python-dev prior to any acceptance. I have recently received a notification that since PEP 470 has been accepted, I can no longer use external hosting for one of the packages that I published on PyPI. The PEP refers to a notice [1] posted on distutils-sig, but I cannot find any discussion of PEP 470 on either python-dev or python-ideas. [1]: https://mail.python.org/pipermail/distutils-sig/2015-September/026789.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP acceptance and SIGs
On September 30, 2015 at 8:20:53 PM, Alexander Belopolsky (alexander.belopol...@gmail.com) wrote: > It has been my understanding that some PEPs may be discussed on specialized > mailings lists, but a notice would be given on python-dev prior to any > acceptance. > I don’t see any requirement to post PEPs to python-dev if they have a Discussions-To header in PEP 1. I don’t really think it makes sense in this case either tbh, PyPI, pip, and setuptools are not under python-dev’s banner. We use PEPs because they are a convenient way to manage change (and we’ve even discussed recently not using PEPs for packaging things that don’t have anything to do with the standard library and moving to a more lightweight process more akin to the Rust RFC process for various reasons). - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP acceptance and SIGs
On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote: > > I don’t see any requirement to post PEPs to python-dev if they have a Discussions-To header in PEP 1. When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is appropriate, with a link to the PEP and an invitation to discuss its merits on datetime-sig." [1] Maybe it is time to clarify that in PEP 1. > I don’t really think it makes sense in this case either tbh, PyPI, pip, and setuptools are not under python-dev’s banner. Given that ensurepip is part of stdlib, I am not sure this is an accurate statement. Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML? My main issue with PEP 470 is that it came shortly after PEP 438 and replaced it. PEP 438 created a solution that was not very convenient, but possible to implement. With PEP 470, you are punishing the developers who took your advise and created verified external distribution assuming that it would remain available for a foreseeable future. By your own count, [2] 59 projects implemented PEP 438 verification in two years since the PEP was published. You compare that to 931 that remain vulnerable and conclude that the solution did not work. Given that information about PEP 438 features was very thinly disseminated, I think 59 is a large number and it would be appropriate to involve the developers of those packages in the discussion that led to PEP 470. [1]: https://mail.python.org/pipermail/datetime-sig/2015-August/000262.html [2]: https://www.python.org/dev/peps/pep-0470/#impact ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP acceptance and SIGs
On Sep 30, 2015, at 09:14 PM, Alexander Belopolsky wrote: >When I faced a similar situation with PEP 495, Guido's advise was "I think >that a courtesy message to python-dev is appropriate, with a link to the >PEP and an invitation to discuss its merits on datetime-sig." [1] Certainly Discussions-To PEPs can be discussed and resolved on mailing lists other than python-dev, and the Resolution header must be set to the URL of the message in that other list that resolves the PEP. A courtesy email to python-dev should go out for all such PEPs, both before resolution (e.g. "hey we're discussing PEP 4000 over on py-in-the-sky-t...@python.org") and after. I do think Standards-Track PEPs (i.e. those that change the language or stdlib) must be discussed and/or posted on python-dev prior to resolution. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP acceptance and SIGs
On September 30, 2015 at 9:14:42 PM, Alexander Belopolsky (alexander.belopol...@gmail.com) wrote: > On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote: > > > > I don’t see any requirement to post PEPs to python-dev if they have a > Discussions-To header in PEP 1. > > > When I faced a similar situation with PEP 495, Guido's advise was "I think > that a courtesy message to python-dev is appropriate, with a link to the > PEP and an invitation to discuss its merits on datetime-sig." [1] > > Maybe it is time to clarify that in PEP 1. An obvious difference is that PEP 495 modifies the standard library and PEP 470 does not (nor do most of the packaging related PEPs, the one that did was discussed on python-dev). > > > I don’t really think it makes sense in this case either tbh, PyPI, pip, > and setuptools are not under python-dev’s banner. > > Given that ensurepip is part of stdlib, I am not sure this is an accurate > statement. PEP 453 states: The bootstrapped software will still remain external to CPython and this PEP does not include CPython subsuming the development responsibilities or design decisions of the bootstrapped software. It was an explicit decision in PEP 453 that these projects still remain independent precisely for this reason. > Even if it was, did you make any effort to discuss the proposal > outside of a small group subscribed to distutils ML? Did I personally? No. The discussion that started PEP 470 actually started on python-dev over a year ago and moved to distutils-sig because people told us to take the packaging stuff off python-dev. However, since it was a PEP, all CPython core developers should have gotten notifications for every modification to the text via the python-checkins mailing list, which all Cpython core developers are expected to be subscribed to. In addition to that, it was also posted as an article to LWN towards the begining of the discussion around it [1]. I don't think it's unreasonable to say that if you want a say in how things are changed, then you should be subscribed to the location where changes get discussed, in this case, distutils-sig. > > My main issue with PEP 470 is that it came shortly after PEP 438 and > replaced it. PEP 438 created a solution that was not very convenient, but > possible to implement. With PEP 470, you are punishing the developers who > took your advise and created verified external distribution assuming that > it would remain available for a foreseeable future. By your own count, > [2] 59 projects implemented PEP 438 verification in two years since the PEP > was published. You compare that to 931 that remain vulnerable and conclude > that the solution did not work. Given that information about PEP 438 > features was very thinly disseminated, I think 59 is a large number and it > would be appropriate to involve the developers of those packages in the > discussion that led to PEP 470. Two years is not a short amount of time in the current pace of Python's packaging evolution. Honestly though, we tried PEP 438 and the end result was pip's users were regularly confused. In hindsight, PEP 438 was not a very good PEP. It was impossible to implement in a way that wasn't massively confusing to end users and indeed, our issue tracker, and my personal email, and IRC got fairly regular complaints from end users due to the confusing state that PEP 438 left us in. With my pip core developer hat on, I decided that it was no longer tennable and I fully planned to implement something to replace PEP 438 regardless of if there was a PEP to back it or not (and as an external project, pip is not bound to follow any PEP, our unofficial policy is to attempt to follow all PEPs unless they are harmful or useless). However I decided that it would be a better overall outcome if PEP 438 was replaced with something that didn't have the problems of PEP 438 and to give folks who cared enough to "show up" to discuss it to have a chance to weigh in on it. I should also mention that it wasn't 59 projects implemented PEP 438 in two years, PEP 438 was explicitly implemented in a way that matched the way that a few projects were already using to get verified downloads. If my memory is correct, there were ~30 some projects that already had PEP 438 compliant URLs so realistically, only ~20 some projects willfully and knowingly took advantage of PEP 438, the rest were just left overs from before. Of those ~20, a handful of them were small projects that were utilities to make PEP 438 easier which aren't really relevant when discussing if PEP 438 was successful or not. > > [1]: https://mail.python.org/pipermail/datetime-sig/2015-August/000262.html > [2]: https://www.python.org/dev/peps/pep-0470/#impact > [1]: https://lwn.net/Articles/599793/ - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@
Re: [Python-Dev] PEP acceptance and SIGs
On 1 October 2015 at 10:19, Alexander Belopolsky wrote: > It has been my understanding that some PEPs may be discussed on specialized > mailings lists, but a notice would be given on python-dev prior to any > acceptance. No, that only applies for changes that actually impact the reference interpreter or the standard library - those still need to be discussed and approved on python-dev. For changes that are wholly decoupled from the reference interpreter (like PyPI behavioural changes), the delegation of authority to the relevant SIG is more complete: = PEP review and resolution may also occur on a list other than python-dev (for example, distutils-sig for packaging related PEPs that don't immediately affect the standard library). In this case, the "Discussions-To" heading in the PEP will identify the appropriate alternative list where discussion, review and pronouncement on the PEP will occur. = (From https://www.python.org/dev/peps/pep-0001/#pep-review-resolution ) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
