Re: [Distutils] Warehouse XMLRPC
On Wed, Mar 05, 2014 at 07:01:49AM -0500, Donald Stufft wrote: On Mar 5, 2014, at 5:48 AM, anatoly techtonik techto...@gmail.com wrote: JSON-RPC is a better choice for recommended external API, because it doesn't rely on memory hungry and potentially unsafe XML libraries. On Wed, Mar 5, 2014 at 3:41 AM, Donald Stufft don...@stufft.io wrote: Just a quick FYI that the last missing piece (search) for XMLRPC was merged in Warehouse today. If you have an application that depends on XMLRPC on PyPI and you’d like to test it, please try against the url: https://pypi-preview.a.ssl.fastly.net/pypi Let me know if you find any issues, or you can file a bug at: https://github.com/pypa/warehouse XMLRPC is used in order to maintain compatibility with what is already there. Something better will replace it eventually and XMLRPC will be deprecated. This is a bit confusing to me now. You're reacting as if anatoly suggested a new JSON interface to replace the legacy XML-RPC one. But the old PyPI codebase already had a JSON API[1]. I'm using it to keep track of Python 3 support status of about 800 packages maintained by the Zope Foundation: http://zope3.pov.lt/py3/ [1] https://wiki.python.org/moin/PyPIJSON I assume at some point Warehouse will add support for the JSON API and you'll issue a call for testing? Marius Gedminas -- The typewriter was invented by Hungarian immigrant Qwert Yuiop, who left his signature on the keyboard. -- Kim signature.asc Description: Digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Warehouse XMLRPC
On Wed, Mar 5, 2014 at 3:01 PM, Donald Stufft don...@stufft.io wrote: XMLRPC is used in order to maintain compatibility with what is already there. Something better will replace it eventually and XMLRPC will be deprecated. Good to know that. Testing XMLRPC is a chance to port handlers to a better API, so if something better already has some forms, or at least a ticket - it will be nice to get subscribed to it. -- anatoly t. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Warehouse XMLRPC
On 06/03/14 20:10, Marius Gedminas wrote: On Wed, Mar 05, 2014 at 07:01:49AM -0500, Donald Stufft wrote: On Mar 5, 2014, at 5:48 AM, anatoly techtonik techto...@gmail.com wrote: JSON-RPC is a better choice for recommended external API, because it doesn't rely on memory hungry and potentially unsafe XML libraries. On Wed, Mar 5, 2014 at 3:41 AM, Donald Stufft don...@stufft.io wrote: Just a quick FYI that the last missing piece (search) for XMLRPC was merged in Warehouse today. If you have an application that depends on XMLRPC on PyPI and you'd like to test it, please try against the url: https://pypi-preview.a.ssl.fastly.net/pypi Let me know if you find any issues, or you can file a bug at: https://github.com/pypa/warehouse XMLRPC is used in order to maintain compatibility with what is already there. Something better will replace it eventually and XMLRPC will be deprecated. This is a bit confusing to me now. You're reacting as if anatoly suggested a new JSON interface to replace the legacy XML-RPC one. But the old PyPI codebase already had a JSON API[1]. I'm using it to keep track of Python 3 support status of about 800 packages maintained by the Zope Foundation: http://zope3.pov.lt/py3/ [1] https://wiki.python.org/moin/PyPIJSON I assume at some point Warehouse will add support for the JSON API and you'll issue a call for testing? Marius Gedminas ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig A JSON-RPC interface is slightly different from a normal 'RESTful JSON' api. PyPI currently offers some normal JSON REST resources, as well as an XML-RPC interface. AFAIK Anatoly was suggesting to replace XML-RPC, with JSON-RPC (not just a JSON API, which as you mention already exists), however the former needs to continue to exist because it is an existing feature that many things use. Also AFAIK, warehouse is currently in the business of gaining feature parity with the current PyPI, after which it will be looked into if or what new APIs will be useful to add to make better clients with. Of course a prime candidate for that might be expanding the current RESTful JSON api. -- Matt Iversen PGP: 0xc046e8a874522973 // 2F04 3DCC D6E6 D5AC D262 2E0B C046 E8A8 7452 2973 signature.asc Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Warehouse XMLRPC
On Mar 6, 2014, at 4:10 AM, Marius Gedminas mar...@pov.lt wrote: On Wed, Mar 05, 2014 at 07:01:49AM -0500, Donald Stufft wrote: On Mar 5, 2014, at 5:48 AM, anatoly techtonik techto...@gmail.com wrote: JSON-RPC is a better choice for recommended external API, because it doesn't rely on memory hungry and potentially unsafe XML libraries. On Wed, Mar 5, 2014 at 3:41 AM, Donald Stufft don...@stufft.io wrote: Just a quick FYI that the last missing piece (search) for XMLRPC was merged in Warehouse today. If you have an application that depends on XMLRPC on PyPI and you’d like to test it, please try against the url: https://pypi-preview.a.ssl.fastly.net/pypi Let me know if you find any issues, or you can file a bug at: https://github.com/pypa/warehouse XMLRPC is used in order to maintain compatibility with what is already there. Something better will replace it eventually and XMLRPC will be deprecated. This is a bit confusing to me now. You're reacting as if anatoly suggested a new JSON interface to replace the legacy XML-RPC one. Well specifically he said JSON-RPC is better than XMLRPC which sounds like he was disagreeing with Warehouse implementing the XMLRPC interface. If that wasn’t the case then I misunderstood :) I don’t think an RPC interface is really needed at all for PyPI. But the old PyPI codebase already had a JSON API[1]. I'm using it to keep track of Python 3 support status of about 800 packages maintained by the Zope Foundation: http://zope3.pov.lt/py3/ [1] https://wiki.python.org/moin/PyPIJSON I assume at some point Warehouse will add support for the JSON API and you'll issue a call for testing? Richard has actually already implemented it! But in testing it just now I see it is failing on the server but isn’t locally for me so I’ll need to see why that is the case. Marius Gedminas -- The typewriter was invented by Hungarian immigrant Qwert Yuiop, who left his signature on the keyboard. -- Kim ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Warehouse XMLRPC
On Thu, Mar 6, 2014 at 3:28 PM, Donald Stufft don...@stufft.io wrote: On Mar 6, 2014, at 4:10 AM, Marius Gedminas mar...@pov.lt wrote: On Wed, Mar 05, 2014 at 07:01:49AM -0500, Donald Stufft wrote: On Mar 5, 2014, at 5:48 AM, anatoly techtonik techto...@gmail.com wrote: JSON-RPC is a better choice for recommended external API, because it doesn't rely on memory hungry and potentially unsafe XML libraries. On Wed, Mar 5, 2014 at 3:41 AM, Donald Stufft don...@stufft.io wrote: Just a quick FYI that the last missing piece (search) for XMLRPC was merged in Warehouse today. If you have an application that depends on XMLRPC on PyPI and you’d like to test it, please try against the url: https://pypi-preview.a.ssl.fastly.net/pypi Let me know if you find any issues, or you can file a bug at: https://github.com/pypa/warehouse XMLRPC is used in order to maintain compatibility with what is already there. Something better will replace it eventually and XMLRPC will be deprecated. This is a bit confusing to me now. You're reacting as if anatoly suggested a new JSON interface to replace the legacy XML-RPC one. Well specifically he said JSON-RPC is better than XMLRPC which sounds like he was disagreeing with Warehouse implementing the XMLRPC interface. If that wasn’t the case then I misunderstood :) I don’t think an RPC interface is really needed at all for PyPI. Let me clarify to avoid further speculations. 1. I forgot that PyPI exposes JSON API 2. I expressed concern that XMLRPC is promoted for integration with PyPI and it should not, because it is ineffective But the old PyPI codebase already had a JSON API[1]. I'm using it to keep track of Python 3 support status of about 800 packages maintained by the Zope Foundation: http://zope3.pov.lt/py3/ [1] https://wiki.python.org/moin/PyPIJSON I assume at some point Warehouse will add support for the JSON API and you'll issue a call for testing? Richard has actually already implemented it! But in testing it just now I see it is failing on the server but isn’t locally for me so I’ll need to see why that is the case. So yes. Use JSON API, but test XMLRPC for compatibility is the thing I expected to hear. =) -- anatoly t. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] tourist here, with a dumb RTFM question
Hi Distutils ! I don’t follow this list and haven’t looked at it in a long time. However, I’m learning via twitter that a brand new setuptools release that’s just gone out has just removed the “Feature” mechanism. Now as you’re all rolling your eyes and preparing to bang out frustrated replies how this was well announced and deprecated and warned about and wow really didn’t you know the term paper was due today, OK first off let me say I am sorry! I am not a distutils/setuptools maintainer.I am just someone that uses it, and as I include setuptools in my setup.py, I am also getting thousands of other people who download my product to use it as well.And I don’t read the setuptools changelog! Or the setuptools blog. Or this list. I assume you guys have it under control (and you certainly do!). There seem to be other people like me (people who write very widely used software) who also seem surprised! And that is surprising too (as I am usually the only person to be surprised by these things that should not be surprising). So I hope you can hold back your frustration with my clueless RTFMness long enough to answer these questions: 1. where was this announced? I’m wondering why there weren’t loud blaring blog posts and tweets all over the place stating that on March 6, dozens of major packages are going to all break. 2. what is the plan for unmaintained packages and old versions of existing packages on pypi that “import Feature” and can no longer be installed?Is it just the case that a large amount of pypi just won’t install anymore? 3. What, if any, is the recommended approach going forward to a Python package that wishes to specify a command-line flag during install. Here’s multiple choice: a. you can use new setuptools API some new way to add —flags b. you can roll it yourself in setup.py using hack X c. your setup.py should never accept any kind of flags as that interferes with up-and-coming use case Q d. other If choice c., then here is another question. My library includes optional C extensions. On certain platforms, these C extensions don’t build (like on Pypy, or on Windows if you don’t have compilation tools installed). In this regard it gracefully degrades. But also, I want to be able to have a command line option to determine this as well. Because! Maybe I’m installing within a test suite where I need to test the entire library without the C extensions built.Maybe some user has found a bug in the C extensions, and that user needs to temporarily install the tool without the extensions built.Other cases for flags are, maybe your library can build with or without SSL support, something like that. Keep in mind, I actually *won’t* be getting bug reports about this because my setup.py already gracefully degrades to distutils! But still, I’d like to have my —without-cextensions flag somehow. Thanks for listening and again I apologize for not following the setuptools changelog on a regular basis! - mike ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Mar 6, 2014, at 12:55 PM, Michael Bayer mike...@zzzcomputing.com wrote: Hi Distutils ! I don’t follow this list and haven’t looked at it in a long time. However, I’m learning via twitter that a brand new setuptools release that’s just gone out has just removed the “Feature” mechanism. Now as you’re all rolling your eyes and preparing to bang out frustrated replies how this was well announced and deprecated and warned about and wow really didn’t you know the term paper was due today, OK first off let me say I am sorry! I am not a distutils/setuptools maintainer.I am just someone that uses it, and as I include setuptools in my setup.py, I am also getting thousands of other people who download my product to use it as well.And I don’t read the setuptools changelog! Or the setuptools blog. Or this list. I assume you guys have it under control (and you certainly do!). There seem to be other people like me (people who write very widely used software) who also seem surprised! And that is surprising too (as I am usually the only person to be surprised by these things that should not be surprising). So I hope you can hold back your frustration with my clueless RTFMness long enough to answer these questions: 1. where was this announced? I’m wondering why there weren’t loud blaring blog posts and tweets all over the place stating that on March 6, dozens of major packages are going to all break. 2. what is the plan for unmaintained packages and old versions of existing packages on pypi that “import Feature” and can no longer be installed?Is it just the case that a large amount of pypi just won’t install anymore? 3. What, if any, is the recommended approach going forward to a Python package that wishes to specify a command-line flag during install. Here’s multiple choice: a. you can use new setuptools API some new way to add —flags b. you can roll it yourself in setup.py using hack X c. your setup.py should never accept any kind of flags as that interferes with up-and-coming use case Q d. other If choice c., then here is another question. My library includes optional C extensions. On certain platforms, these C extensions don’t build (like on Pypy, or on Windows if you don’t have compilation tools installed). In this regard it gracefully degrades. But also, I want to be able to have a command line option to determine this as well. Because! Maybe I’m installing within a test suite where I need to test the entire library without the C extensions built.Maybe some user has found a bug in the C extensions, and that user needs to temporarily install the tool without the extensions built.Other cases for flags are, maybe your library can build with or without SSL support, something like that. Keep in mind, I actually *won’t* be getting bug reports about this because my setup.py already gracefully degrades to distutils! But still, I’d like to have my —without-cextensions flag somehow. Thanks for listening and again I apologize for not following the setuptools changelog on a regular basis! - mike ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig FWIW as the person who was mostly the responder on Twitter, I really didn’t mean to sound RTFM-y. I think that communicating things to users is *important*. I was mostly just responding to the fact it wasn’t completely out of the blue :) As far as I’m aware here are the answers: 1. Setuptools changelog in Version 1.0 2. Use older versions of setuptools 3. No idea. Please note that I’m not the setuptools maintainer and these are just what I’m aware of. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
pje said: The Feature() facility was never completely implemented or supported, and even if it were, it should be deprecated now, as it will not be compatible with the coming packaging systems based on PEP 426. If you need separate features, use separate distributions and extras instead. (The problem I discovered when I first implemented Feature is that distutils' build system really isn't capable of having a sane configure step, or saving that configuration. Essentially, distutils is a little too stateless for that, but Features need it in order not to act weird in various scenarios. Extras are basically the intended replacement for this functionality, and Features were just kept around to support legacy projects.) See also https://bitbucket.org/pypa/setuptools/issue/58 https://bitbucket.org/pypa/setuptools/issue/65 On Thu, Mar 6, 2014 at 12:55 PM, Michael Bayer mike...@zzzcomputing.com wrote: Hi Distutils ! I don't follow this list and haven't looked at it in a long time. However, I'm learning via twitter that a brand new setuptools release that's just gone out has just removed the Feature mechanism. Now as you're all rolling your eyes and preparing to bang out frustrated replies how this was well announced and deprecated and warned about and wow really didn't you know the term paper was due today, OK first off let me say I am sorry! I am not a distutils/setuptools maintainer.I am just someone that uses it, and as I include setuptools in my setup.py, I am also getting thousands of other people who download my product to use it as well.And I don't read the setuptools changelog! Or the setuptools blog. Or this list. I assume you guys have it under control (and you certainly do!). There seem to be other people like me (people who write very widely used software) who also seem surprised! And that is surprising too (as I am usually the only person to be surprised by these things that should not be surprising). So I hope you can hold back your frustration with my clueless RTFMness long enough to answer these questions: 1. where was this announced? I'm wondering why there weren't loud blaring blog posts and tweets all over the place stating that on March 6, dozens of major packages are going to all break. 2. what is the plan for unmaintained packages and old versions of existing packages on pypi that import Feature and can no longer be installed?Is it just the case that a large amount of pypi just won't install anymore? 3. What, if any, is the recommended approach going forward to a Python package that wishes to specify a command-line flag during install. Here's multiple choice: a. you can use new setuptools API some new way to add --flags b. you can roll it yourself in setup.py using hack X c. your setup.py should never accept any kind of flags as that interferes with up-and-coming use case Q d. other If choice c., then here is another question. My library includes optional C extensions. On certain platforms, these C extensions don't build (like on Pypy, or on Windows if you don't have compilation tools installed). In this regard it gracefully degrades. But also, I want to be able to have a command line option to determine this as well. Because! Maybe I'm installing within a test suite where I need to test the entire library without the C extensions built.Maybe some user has found a bug in the C extensions, and that user needs to temporarily install the tool without the extensions built.Other cases for flags are, maybe your library can build with or without SSL support, something like that. Keep in mind, I actually *won't* be getting bug reports about this because my setup.py already gracefully degrades to distutils! But still, I'd like to have my --without-cextensions flag somehow. Thanks for listening and again I apologize for not following the setuptools changelog on a regular basis! - mike ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Mar 6, 2014, at 12:55 PM, Michael Bayer mike...@zzzcomputing.com wrote: changelog! Or the setuptools blog. Or this list. I assume you guys have it under control (and you certainly do!). There seem to be other people like me (people please note this correction to my last email: “I assume you guys have it under control” should read: “I assume you folks have it under control”.I apologize for this mistake. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Mar 6, 2014, at 1:07 PM, Daniel Holth dho...@gmail.com wrote: pje said: The Feature() facility was never completely implemented or supported, and even if it were, it should be deprecated now, as it will not be compatible with the coming packaging systems based on PEP 426. If you need separate features, use separate distributions and extras instead. wait, ok this is that thing. “separate distributions” means…. SQLAlchemy-0.9.3-nocext.tar.gz SQLAlchemy-0.9.3-cext.tar.gz ?? I think that’s what it means.OK, not sure if I have to say this but that would be…OK very very unworkable. A Python package distribution is a *source distribution*. That suggests that one need to package up separate source distributions in order to specify an option, is… OK very very unworkable. (note by “very very unworkable” I mean “list of hyperboles I had to backspace out because that’s not why I’m here”). If a package has three flags, now there need to be *eight source distros*? Really? On the plus side, I just used math. how does one even maintain this in source control? Do I have setup.py.nocext, setup.py.cext, maintain a copy of 99% the same code in each, then rename them when I do “python setup.py sdist” (since sdist doesn’t take command line options either!!) ? The suggestion is completely inappropriate. I don’t know the metadata format in pep426 well enough to comment (as I wanted to use it one day and found that it seemed to still be pretty much vapor), but I’ll reiterate: these are source distributions, not binaries or wheels or anything like that. A source distro has to build, and builds need options. A metadata format that purports to represent metadata about a source distribution and does not support flags is a broken metadata format. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
It is certainly broken. On Thu, Mar 6, 2014 at 1:37 PM, Michael Bayer mike...@zzzcomputing.com wrote: On Mar 6, 2014, at 1:07 PM, Daniel Holth dho...@gmail.com wrote: pje said: The Feature() facility was never completely implemented or supported, and even if it were, it should be deprecated now, as it will not be compatible with the coming packaging systems based on PEP 426. If you need separate features, use separate distributions and extras instead. wait, ok this is that thing. separate distributions means SQLAlchemy-0.9.3-nocext.tar.gz SQLAlchemy-0.9.3-cext.tar.gz ?? I think that's what it means.OK, not sure if I have to say this but that would be...OK very very unworkable. A Python package distribution is a *source distribution*. That suggests that one need to package up separate source distributions in order to specify an option, is... OK very very unworkable. (note by very very unworkable I mean list of hyperboles I had to backspace out because that's not why I'm here). If a package has three flags, now there need to be *eight source distros*? Really? On the plus side, I just used math. how does one even maintain this in source control? Do I have setup.py.nocext, setup.py.cext, maintain a copy of 99% the same code in each, then rename them when I do python setup.py sdist (since sdist doesn't take command line options either!!) ? The suggestion is completely inappropriate. I don't know the metadata format in pep426 well enough to comment (as I wanted to use it one day and found that it seemed to still be pretty much vapor), but I'll reiterate: these are source distributions, not binaries or wheels or anything like that. A source distro has to build, and builds need options.A metadata format that purports to represent metadata about a source distribution and does not support flags is a broken metadata format. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
Michael Bayer mike_mp at zzzcomputing.com writes: I don’t know the metadata format in pep426 well enough to comment (as I wanted to use it one day and found that it seemed to still be pretty much vapor), but I’ll reiterate: these are source distributions, not binaries or wheels or anything like that. A source distro has to build, and builds need options.A metadata format that purports to represent metadata about a source distribution and does not support flags is a broken metadata format. PEP 426 only covers installation metadata - its scope does not cover source distributions (there will be another PEP covering that). Apart from the most recent changes being not yet implemented and some open issues relating to hooks, PEP 426 seems to cover installation metadata reasonably well. However, sdist metadata is a different kettle of fish. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Mar 6, 2014, at 2:59 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Michael Bayer mike_mp at zzzcomputing.com writes: I don’t know the metadata format in pep426 well enough to comment (as I wanted to use it one day and found that it seemed to still be pretty much vapor), but I’ll reiterate: these are source distributions, not binaries or wheels or anything like that. A source distro has to build, and builds need options.A metadata format that purports to represent metadata about a source distribution and does not support flags is a broken metadata format. PEP 426 only covers installation metadata - its scope does not cover source distributions (there will be another PEP covering that). Apart from the most recent changes being not yet implemented and some open issues relating to hooks, PEP 426 seems to cover installation metadata reasonably well. However, sdist metadata is a different kettle of fish. OK so why does PEP-426 compatibility imply removal of command line switches from setup.py files ? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Thu, Mar 6, 2014 at 10:37 AM, Michael Bayer mike...@zzzcomputing.comwrote: On Mar 6, 2014, at 1:07 PM, Daniel Holth dho...@gmail.com wrote: pje said: The Feature() facility was never completely implemented or supported, and even if it were, it should be deprecated now, as it will not be compatible with the coming packaging systems based on PEP 426. If you need separate features, use separate distributions and extras instead. wait, ok this is that thing. separate distributions means SQLAlchemy-0.9.3-nocext.tar.gz SQLAlchemy-0.9.3-cext.tar.gz I'm new to understanding setuptools Feature myself, so don't crank too much, if I get anything wrong. afaik, it means something like: SQLAlchemy-X.Y.tar.gz SQLAlchemy-cext-X.Y.tar.gz i.e. isolating the feature into a separate project. and then instead of having the handy --with-cext option, it has to be pip install SQLAlchemy[SQLAlchemy-cext] PJ, Jason: can you clarify what the alternative is supposed to look like? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
Donald Stufft donald at stufft.io writes: 2. Use older versions of setuptools That's not really an answer, unless downgrading works. For example, a recently created venv would contain the latest setuptools, and perhaps it would be required by other distributions in the venv. How then would e.g. SQLAlchemy specify that an older setuptools version should be used? Would pip downgrade the venv's setuptools to an older version? Even if it did, might that not break other distributions in the venv? Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Mar 6, 2014, at 4:15 PM, Marcus Smith qwc...@gmail.com wrote: On Thu, Mar 6, 2014 at 10:37 AM, Michael Bayer mike...@zzzcomputing.com wrote: On Mar 6, 2014, at 1:07 PM, Daniel Holth dho...@gmail.com wrote: pje said: The Feature() facility was never completely implemented or supported, and even if it were, it should be deprecated now, as it will not be compatible with the coming packaging systems based on PEP 426. If you need separate features, use separate distributions and extras instead. wait, ok this is that thing. “separate distributions” means…. SQLAlchemy-0.9.3-nocext.tar.gz SQLAlchemy-0.9.3-cext.tar.gz I'm new to understanding setuptools Feature myself, so don't crank too much, if I get anything wrong. afaik, it means something like: SQLAlchemy-X.Y.tar.gz SQLAlchemy-cext-X.Y.tar.gz i.e. isolating the feature into a separate project. and then instead of having the handy --with-cext option, it has to be pip install SQLAlchemy[SQLAlchemy-cext] This is my understanding as well except it inverses the default. SQLAlchemy wants the C exts installed unless they can't be if the user opts out. Extras would cause if to not be installed unless the user opts in. This is probably not a reasonable solution. One note if could just be SQLAlchemy[cext] PJ, Jason: can you clarify what the alternative is supposed to look like? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
From:Michael Bayer mike...@zzzcomputing.com OK so why does PEP-426 compatibility imply removal of command line switches from setup.py files ? As far as I know, it doesn't. My distil tools complies with a fairly recent version of PEP 426 and AFAIK has no problem building / installing SQLAlchemy with / without extensions, but it uses an extended set of metadata which is not specified in any PEP - for example, http://www.red-dove.com/pypi/projects/S/SQLAlchemy/package-0.9.3.json This is just FYI - it's experimental metadata [which has some redundancy for historical reasons, to be tidied up in the future] and is extracted from what is passed to setup.py - it includes the PEP 426 metadata as a subset (index-metadata), and the extra stuff is needed for building. This is used by the distil tool, but there's no support for any specific command-line flags to exclude the building extensions. (That's not because of PEP compliance - it's just that I haven't needed that level of control in the tool.) Regards, Vinay Sajip___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
This is my understanding as well except it inverses the default. SQLAlchemy wants the C exts installed unless they can't be if the user opts out. Extras would cause if to not be installed unless the user opts in. This is probably not a reasonable solution. ok, that's odd, so there is no extras replacement for the --without-cext scenario. so even more important to understand from PJ/Jason the rationale of how Feature could be removed One note if could just be SQLAlchemy[cext] oh yea, you just pass a label ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] tourist here, with a dumb RTFM question
On Mar 6, 2014, at 4:35 PM, Marcus Smith qwc...@gmail.com wrote: This is my understanding as well except it inverses the default. SQLAlchemy wants the C exts installed unless they can't be if the user opts out. Extras would cause if to not be installed unless the user opts in. This is probably not a reasonable solution. ok, that's odd, so there is no extras replacement for the --without-cext scenario. so even more important to understand from PJ/Jason the rationale of how Feature could be removed One note if could just be SQLAlchemy[cext] oh yea, you just pass a label show me that ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] OS X and PEP 425 / wheels
Hello,
I proposed a patch https://github.com/pypa/pip/pull/1465 to pip, with
respect to treatment of the platform tag on OS X, and Chris Barker proposed
that I bring the discussion here.
The situation:
PEP 425 describes the platform tag as:
The platform tag is simply distutils.util.get*platform() with all hyphens -
and periods . replaced with underscore *.
but the PEP makes no mention of what should be done on OS X. On OS X,
get_platform() has the form:
macosx_10_6_intel
where 10_6 indicates that the OS X deployment target (of Python) is 10.6,
and intel indicates that it is a fat binary with both x86_64 and i386.
Other values for the arch include ‘ppc’, ‘ppc64’, and ‘universal’, another
multi-arch tag indicating a fat binary with all four of 32/64bit intel and
ppc.
Where PEP 425 causes problems (or pip’s implementation thereof), is in
testing strict equality of this value, not taking into account the meaning
of its contents. I proposed two changes:
1.
Use = comparison for the deployment target
From the OS X platform
documentationhttps://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
:
Choose a deployment target. This identifies the earliest OS version on
which your software can run.
so a binary with deployment target = 10.6 should be installable on OS X
= 10.6.
This change restores the longstanding behavior of easy_install, where
10.6 eggs are installable on = 10.6.
2.
support multi-arch names (intel, universal) on their respective
components
- intel is valid on {x86_64, i386}
- universal is valid on {intel, x86_64, i386, ppc64, ppc}
easy_install, like pip, also does strict comparison here, so this would
be new behavior.
My actual use case:
I have a wheel (pyzmq), which works on any intel-based Python targeting OS
X = 10.6. To express this with pip-1.5, the filename has to be:
pyzmq-14.1.0-cp27-none-macosx_10_6_intel.macosx_10_6_x86_64.macosx_10_6_i386.macosx_10_7_intel.macosx_10_7_x86_64.macosx_10_7_i386.macosx_10_8_intel.macosx_10_8_x86_64.macosx_10_8_i386.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_9_i386.whl
and it has to grow every time there is a new OS release.
With both proposed changes, I could communicate the same information with
just one tag:
pyzmq-14.1.0-cp27-none-macosx_10_6_intel.whl
With just the first change, it would need three:
pyzmq-14.1.0-cp27-none-macosx_10_6_intel.macosx_10_6_x86_64.macosx_10_6_i386.whl
Any feedback from experts, especially if my understanding of deployment
targets or fat binaries is incorrect, would be much appreciated.
Thanks,
-MinRK
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] OS X and PEP 425 / wheels
In article
cahnn8bw+ufqrfqsuszq81whm+xtheb-rp-d9na0tkttgjph...@mail.gmail.com,
MinRK benjami...@gmail.com wrote:
I proposed a patch https://github.com/pypa/pip/pull/1465 to pip, with
respect to treatment of the platform tag on OS X, and Chris Barker proposed
that I bring the discussion here.
The situation:
PEP 425 describes the platform tag as:
The platform tag is simply distutils.util.get*platform() with all hyphens -
and periods . replaced with underscore *.
but the PEP makes no mention of what should be done on OS X. On OS X,
get_platform() has the form:
macosx_10_6_intel
where 10_6 indicates that the OS X deployment target (of Python) is 10.6,
and intel indicates that it is a fat binary with both x86_64 and i386.
Other values for the arch include 'ppc', 'ppc64', and 'universal', another
multi-arch tag indicating a fat binary with all four of 32/64bit intel and
ppc.
As I commented in your pull request, the complete set of universal arch
values is fat, intel, fat3, fat64, and universal besides the
single arch values ppc, ppc64, i386, and x86_64. It would be
best if all of them were supported in pip.
Where PEP 425 causes problems (or pip's implementation thereof), is in
testing strict equality of this value, not taking into account the meaning
of its contents. I proposed two changes:
1.
Use = comparison for the deployment target
From the OS X platform
documentationhttps://developer.apple.com/library/mac/documentation/DeveloperT
ools/Conceptual/cross_development/Configuring/configuring.html
:
Choose a deployment target. This identifies the earliest OS version on
which your software can run.
so a binary with deployment target = 10.6 should be installable on OS X
= 10.6.
This change restores the longstanding behavior of easy_install, where
10.6 eggs are installable on = 10.6.
2.
support multi-arch names (intel, universal) on their respective
components
- intel is valid on {x86_64, i386}
- universal is valid on {intel, x86_64, i386, ppc64, ppc}
easy_install, like pip, also does strict comparison here, so this would
be new behavior.
[...]
With both proposed changes, I could communicate the same information with
just one tag:
pyzmq-14.1.0-cp27-none-macosx_10_6_intel.whl
Any feedback from experts, especially if my understanding of deployment
targets or fat binaries is incorrect, would be much appreciated.
Thanks for actually proposing an implementation of this. I think both
changes should be implemented, with the proviso that all universal arch
values are supported (for example, the fat universal arch is still
used in current 32-bit-only python.org Pythons. As I also noted in the
comments, it is not a perfect solution since it doesn't cover all
possible cases (like Unicode ABI). That will have to wait for Metadata
2.0. But it does provide important usability gains for OS X users right
now and covers the most common (by far) use cases.
--
Ned Deily,
n...@acm.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] OS X and PEP 425 / wheels
On Thu, Mar 6, 2014 at 4:27 PM, MinRK benjami...@gmail.com wrote:
I proposed a patch https://github.com/pypa/pip/pull/1465 to pip, with
respect to treatment of the platform tag on OS X, and Chris Barker proposed
that I bring the discussion here.
Note -- there is some more discusion on that patch...
The situation:
PEP 425 describes the platform tag as:
The platform tag is simply distutils.util.get*platform() with all hyphens
- and periods . replaced with underscore *.
but the PEP makes no mention of what should be done on OS X. On OS X,
get_platform() has the form:
macosx_10_6_intel
.
1.
2.
support multi-arch names (intel, universal) on their respective
components
- intel is valid on {x86_64, i386}
- universal is valid on {intel, x86_64, i386, ppc64, ppc}
easy_install, like pip, also does strict comparison here, so this
would be new behavior.
yup -- and easy_install was actually quite broken for binary eggs for a
universal build -- so this would be great.
though a note: universal:, as used by the python.org builds means
only i386+ppc -- in theory once could do a quad build, but no on ever did.
Though ppc is pretty old now -- I don't think we need to worry about that
for anything future-looking anyway.
I have a wheel (pyzmq), which works on any intel-based Python targeting OS
X = 10.6. To express this with pip-1.5, the filename has to be:
pyzmq-14.1.0-cp27-none-macosx_10_6_intel.macosx_10_6_x86_64.macosx_10_6_i386.macosx_10_7_intel.macosx_10_7_x86_64.macosx_10_7_i386.macosx_10_8_intel.macosx_10_8_x86_64.macosx_10_8_i386.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_9_i386.whl
and it has to grow every time there is a new OS release.
clearly no ideal!
Any feedback from experts, especially if my understanding of deployment
targets or fat binaries is incorrect, would be much appreciated.
I'm no expert, but his looks good to me.
As pointed out in the comments on the patch, there may be some issues with
C++ extensions and building on 10.9 -- we'll have to see how that turns
out
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Warehouse XMLRPC
On Mar 6, 2014, at 7:28 AM, Donald Stufft don...@stufft.io wrote: But the old PyPI codebase already had a JSON API[1]. I'm using it to keep track of Python 3 support status of about 800 packages maintained by the Zope Foundation: http://zope3.pov.lt/py3/ [1] https://wiki.python.org/moin/PyPIJSON I assume at some point Warehouse will add support for the JSON API and you'll issue a call for testing? Richard has actually already implemented it! But in testing it just now I see it is failing on the server but isn’t locally for me so I’ll need to see why that is the case. The JSON API is functional again and is available for testing! - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
