Re: [Distutils] Deprecate and Block requires/provides
What do people think? +1 Perhaps Obsoletes, too, if that's used anywhere (Superseded by Obsoleted-By). Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On 17 Oct 2013 13:02, Donald Stufft don...@stufft.io wrote: As many are aware distutils has the requires field and such. These fields are designed to list something you *import* not something you install from PyPI. I believe these fields to be generally useless, supported by the fact distutils2 deprecated them, and outright user hostile. Users do not tend to realize that these aren't PyPI distributions and attempt to use them for that case. This generally works in that it will show up on PyPI but it will fail as soon as a distribution contains a character like -. So what I would like to do is remove these fields. This would consist of modifying PyPI to return an error code if they are included and hiding the existing data in the UX. It might at a future time also consist of removing the data from the DB all together. What do people think? Don't break things when they don't pose an immediate security threat (and sometimes not even then) :) For this case, I like the idea of adding a note on projects where these fields are displayed saying something like These metadata fields are obsolete and ignored by installation tools. Use setuptools metadata to declare dependencies on other PyPI projects. (with an appropriate hyperlink from setuptools metadata). And then maybe another caremad page listing projects that still use the obsolete fields :) Cheers, Nick. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] Deprecate and Block requires/provides
On 17 October 2013 04:01, Donald Stufft don...@stufft.io wrote: As many are aware distutils has the requires field and such. These fields are designed to list something you *import* not something you install from PyPI. I believe these fields to be generally useless, supported by the fact distutils2 deprecated them, and outright user hostile. Users do not tend to realize that these aren't PyPI distributions and attempt to use them for that case. This generally works in that it will show up on PyPI but it will fail as soon as a distribution contains a character like -. So what I would like to do is remove these fields. This would consist of modifying PyPI to return an error code if they are included and hiding the existing data in the UX. It might at a future time also consist of removing the data from the DB all together. What do people think? +1 to hiding them in the PyPI UI. -1 to breaking setup.py upload / register ! Michael - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - Packaging is confusing enough without leaving foot guns littered through it. On Oct 17, 2013, at 6:04 AM, Nick Coghlan ncogh...@gmail.com wrote: Don't break things when they don't pose an immediate security threat (and sometimes not even then) :) ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Wed, Oct 16, 2013 at 11:01 PM, Donald Stufft don...@stufft.io wrote: So what I would like to do is remove these fields. This would consist of modifying PyPI to return an error code if they are included and hiding the existing data in the UX. It might at a future time also consist of removing the data from the DB all together. What do people think? IIUC, you're proposing to error on uploads of distributions with these fields set. This wouldn't effect distributions already uploaded and wouldn't cause (new) breakage for consumers of those distributions. The only breakage would be for authors uploading the buggy distributions. These are the people who could actually address the breakage and who would benefit from the breakage by finding out that they have a bug in their distributions. This seems an appropriate form of breakage to me, so +1. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 7:19 AM, Donald Stufft don...@stufft.io wrote: For some numbers, 6% of the projects hosted on PyPI have *ever* uploaded a release using the requires field. (This does not mean they are actively using it, just that at least once they did use it). I think that's a pretty low number of affected users, especially when they can immediately fix it and I can provide an error message telling them what to do. More numbers (total number of uses): requires - 17492 provides - 3876 obsoletes - 176 requires_dist - 120 (Would Break Wheels) provides_dist - 0 obsoletes_dist - 0 requires_external - 9 (all the same project) I think we should deprecate/remove requires, provides, obsoletes, obsoletes_dist, and requires_externals. The first 3 were already deprecated with PEP345 so it would just be a matter of removing PyPI support for them, the other two are not/barely used and don't jive with PEP426. Since they are basically unused I think it would make sense to just kill them now to simplify DB schema and UX so we don't need to compensate for the case where they might exist. - 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] Deprecate and Block requires/provides
On 17 October 2013 21:14, Jim Fulton j...@zope.com wrote: On Wed, Oct 16, 2013 at 11:01 PM, Donald Stufft don...@stufft.io wrote: So what I would like to do is remove these fields. This would consist of modifying PyPI to return an error code if they are included and hiding the existing data in the UX. It might at a future time also consist of removing the data from the DB all together. What do people think? IIUC, you're proposing to error on uploads of distributions with these fields set. This wouldn't effect distributions already uploaded and wouldn't cause (new) breakage for consumers of those distributions. The only breakage would be for authors uploading the buggy distributions. These are the people who could actually address the breakage and who would benefit from the breakage by finding out that they have a bug in their distributions. This seems an appropriate form of breakage to me, so +1. Except we can't tell if it's a human or a script doing the upload, and if it's the latter, we just broke somebody's automated release process without anything even remotely approaching adequate justification. PyPI is a trusted service provider: we can nudge people towards better ways of doing things, but something has to pose an imminent threat to the integrity of the service itself for us to consider breaking backwards compatibility. That's why I suggested following the same approach as Donald did for reducing the amount of external scanning going on: creating a separate list of all the projects still using the deprecated metadata, and encouraging users of those projects to get in touch with the maintainers. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 8:49 AM, Nick Coghlan ncogh...@gmail.com wrote: Except we can't tell if it's a human or a script doing the upload, and if it's the latter, we just broke somebody's automated release process without anything even remotely approaching adequate justification. Even if it breaks it, it's for a small number of users, 931 total projects in 2928 releases in the last year have submitted something using the ``requires`` field. Looking through the data for these it appears that most of them are NOT using it correctly. I'd be willing to bet money that the people who are using it are just trying to get dependency information to show up on PyPI, which they can do now using Wheel + Twine. It's an attractive nuisance // foot gun, it confuses uses, and by continuing to allow it we are making packaging more confusing for users. PyPI is a trusted service provider: we can nudge people towards better ways of doing things, but something has to pose an imminent threat to the integrity of the service itself for us to consider breaking backwards compatibility. I'm not sure I agree with this. PyPI isn't versioned so unless we deprecate and remove things it's going to just get cruftier and cruftier. For instance An API might end up with 3 or more different concepts of obsoletes because we were unwilling to remove older metadata that is no longer in use. That is actively making the entire system harder to use. That's not to say we should just willy nilly remove stuff, but this seems like a prime candidate for removal as it is a common pain point that i've seen new users trying to package things stumble on. That's why I suggested following the same approach as Donald did for reducing the amount of external scanning going on: creating a separate list of all the projects still using the deprecated metadata, and encouraging users of those projects to get in touch with the maintainers. - 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] Deprecate and Block requires/provides
On 17 October 2013 23:22, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 8:49 AM, Nick Coghlan ncogh...@gmail.com wrote: Except we can't tell if it's a human or a script doing the upload, and if it's the latter, we just broke somebody's automated release process without anything even remotely approaching adequate justification. Even if it breaks it, it's for a small number of users, 931 total projects in 2928 releases in the last year have submitted something using the ``requires`` field. Looking through the data for these it appears that most of them are NOT using it correctly. You're not allowed to upload to PyPI any more until you fix this thing that we were previously OK with is a lousy way to educate them. I'd be willing to bet money that the people who are using it are just trying to get dependency information to show up on PyPI, which they can do now using Wheel + Twine. It's an attractive nuisance // foot gun, it confuses uses, and by continuing to allow it we are making packaging more confusing for users. I'm fine with turning it off for projects that don't already use this data. I'm *not* fine with breaking something that was working for people. PyPI is a trusted service provider: we can nudge people towards better ways of doing things, but something has to pose an imminent threat to the integrity of the service itself for us to consider breaking backwards compatibility. I'm not sure I agree with this. PyPI isn't versioned so unless we deprecate and remove things it's going to just get cruftier and cruftier. For instance An API might end up with 3 or more different concepts of obsoletes because we were unwilling to remove older metadata that is no longer in use. That is actively making the entire system harder to use. I'm not opposed to deprecating and removing it. I'm opposed to just turning it off cold for projects where it was previously working. That's not to say we should just willy nilly remove stuff, but this seems like a prime candidate for removal as it is a common pain point that i've seen new users trying to package things stumble on. Yes, but breaking these users' uploads is not the way to do that. That's an incredibly user hostile step to take, and the problem doesn't even come close to justifying breaking even a not-really-working process (since you can work around the current breakage by manually installing the dependencies - you can't work around an inability to upload without making changes to your code). If you really wanted to push them towards fixing their releases, you could always have PyPI send them an email saying something like: Hi, an automated scan of PyPI has shown that you're currently uploading metadata that uses the obsolete module dependency fields defined by distutils. These fields aren't actually checked by automated installation tools like pip, so if you're attempting to indicate that your project depends on other PyPI projects, this mechanism doesn't actually work to achieve that. At some point in the future, PyPI may disallow use of these fields entirely, so if you'd like to declare your dependencies in a way that automated tools can process, you may want to look at using the dependency declaration features in setuptools rather than using plain distutils. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 9:53 AM, Nick Coghlan ncogh...@gmail.com wrote: On 17 October 2013 23:22, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 8:49 AM, Nick Coghlan ncogh...@gmail.com wrote: Except we can't tell if it's a human or a script doing the upload, and if it's the latter, we just broke somebody's automated release process without anything even remotely approaching adequate justification. Even if it breaks it, it's for a small number of users, 931 total projects in 2928 releases in the last year have submitted something using the ``requires`` field. Looking through the data for these it appears that most of them are NOT using it correctly. You're not allowed to upload to PyPI any more until you fix this thing that we were previously OK with is a lousy way to educate them. I'd be willing to bet money that the people who are using it are just trying to get dependency information to show up on PyPI, which they can do now using Wheel + Twine. It's an attractive nuisance // foot gun, it confuses uses, and by continuing to allow it we are making packaging more confusing for users. I'm fine with turning it off for projects that don't already use this data. I'm *not* fine with breaking something that was working for people. PyPI is a trusted service provider: we can nudge people towards better ways of doing things, but something has to pose an imminent threat to the integrity of the service itself for us to consider breaking backwards compatibility. I'm not sure I agree with this. PyPI isn't versioned so unless we deprecate and remove things it's going to just get cruftier and cruftier. For instance An API might end up with 3 or more different concepts of obsoletes because we were unwilling to remove older metadata that is no longer in use. That is actively making the entire system harder to use. I'm not opposed to deprecating and removing it. I'm opposed to just turning it off cold for projects where it was previously working. It's been deprecated since 2010 (and the PEP that deprecated it was created in 2005). That's not to say we should just willy nilly remove stuff, but this seems like a prime candidate for removal as it is a common pain point that i've seen new users trying to package things stumble on. Yes, but breaking these users' uploads is not the way to do that. That's an incredibly user hostile step to take, and the problem doesn't even come close to justifying breaking even a not-really-working process (since you can work around the current breakage by manually installing the dependencies - you can't work around an inability to upload without making changes to your code). If you really wanted to push them towards fixing their releases, you could always have PyPI send them an email saying something like: Hi, an automated scan of PyPI has shown that you're currently uploading metadata that uses the obsolete module dependency fields defined by distutils. These fields aren't actually checked by automated installation tools like pip, so if you're attempting to indicate that your project depends on other PyPI projects, this mechanism doesn't actually work to achieve that. At some point in the future, PyPI may disallow use of these fields entirely, so if you'd like to declare your dependencies in a way that automated tools can process, you may want to look at using the dependency declaration features in setuptools rather than using plain distutils. This could be part of the deprecation process, but unless there's a plan in place to deprecate them I don't know how useful this email would be. It's a reactive warning to something that confuses people while they are creating a package. In other words by the time the email goes out they've already been confused. Perhaps this needs a PEP to specify a warning period with emails and then ultimately removal. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia - 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] Deprecate and Block requires/provides
On Thu, Oct 17, 2013 at 9:53 AM, Nick Coghlan ncogh...@gmail.com wrote: Yes, but breaking these users' uploads is not the way to do that. That's an incredibly user hostile step to take, and the problem doesn't even come close to justifying breaking even a not-really-working process (since you can work around the current breakage by manually installing the dependencies - you can't work around an inability to upload without making changes to your code). +1 I can imagine that from many users' perspectives you're doing it wrong isn't even true. The docs for distutils *still* read: Dependencies on other Python modules and packages can be specified by supplying the requires keyword argument to setup() and A package can declare that it obsoletes other packages using the obsoletes keyword argument and nowhere does it read but these keywords are broken and obsolete as of some obscure PEP and you're wrong to have used them. If you really wanted to push them towards fixing their releases, you could always have PyPI send them an email saying something like: Hi, an automated scan of PyPI has shown that you're currently uploading metadata that uses the obsolete module dependency fields defined by distutils. These fields aren't actually checked by automated installation tools like pip, so if you're attempting to indicate that your project depends on other PyPI projects, this mechanism doesn't actually work to achieve that. At some point in the future, PyPI may disallow use of these fields entirely, so if you'd like to declare your dependencies in a way that automated tools can process, you may want to look at using the dependency declaration features in setuptools rather than using plain distutils. I was just going to ask--why not at least try to e-mail the maintainers of those packages? If they're unreachable to begin with then I'm a little less concerned. But at least give those who might care a direct heads up about where things are going. Then when the inevitable complaints do come in at least you've covered your ass :) Best, Erik ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Thu, Oct 17, 2013 at 09:59:58AM -0400, Donald Stufft wrote: On Oct 17, 2013, at 9:53 AM, Nick Coghlan ncogh...@gmail.com wrote: Yes, but breaking these users' uploads is not the way to do that. That's an incredibly user hostile step to take, and the problem doesn't even come close to justifying breaking even a not-really-working process (since you can work around the current breakage by manually installing the dependencies - you can't work around an inability to upload without making changes to your code). If you really wanted to push them towards fixing their releases, you could always have PyPI send them an email saying something like: ... This could be part of the deprecation process, but unless there's a plan in place to deprecate them I don't know how useful this email would be. It's a reactive warning to something that confuses people while they are creating a package. In other words by the time the email goes out they've already been confused. Is it possible to make 'python setup.py sdist upload' emit a warning message about using these deprecated fields, without rejecting the upload? Marius Gedminas -- Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. signature.asc Description: Digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 10:38 AM, Marius Gedminas mar...@pov.lt wrote: On Thu, Oct 17, 2013 at 09:59:58AM -0400, Donald Stufft wrote: On Oct 17, 2013, at 9:53 AM, Nick Coghlan ncogh...@gmail.com wrote: Yes, but breaking these users' uploads is not the way to do that. That's an incredibly user hostile step to take, and the problem doesn't even come close to justifying breaking even a not-really-working process (since you can work around the current breakage by manually installing the dependencies - you can't work around an inability to upload without making changes to your code). If you really wanted to push them towards fixing their releases, you could always have PyPI send them an email saying something like: ... This could be part of the deprecation process, but unless there's a plan in place to deprecate them I don't know how useful this email would be. It's a reactive warning to something that confuses people while they are creating a package. In other words by the time the email goes out they've already been confused. Is it possible to make 'python setup.py sdist upload' emit a warning message about using these deprecated fields, without rejecting the upload? I don't believe so (but don't quote me on that), besides the obvious of patching distutils. Marius Gedminas -- Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. ___ 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] Deprecate and Block requires/provides
On 17 October 2013 11:56, Donald Stufft don...@stufft.io wrote: Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - You're proposing replacing arguably broken (by some definition) with actually broken (no longer works). That's not an acceptable trade-off. Packaging is confusing enough without leaving foot guns littered through it. Packaging is confusing enough without breaking people's stuff! (Replacing a foot gun with actually shooting people's feet off if we're going to stick with the metaphor...) Michael On Oct 17, 2013, at 6:04 AM, Nick Coghlan ncogh...@gmail.com wrote: Don't break things when they don't pose an immediate security threat (and sometimes not even then) :) ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Thu, Oct 17, 2013 at 11:20 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 11:56, Donald Stufft don...@stufft.io wrote: Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - You're proposing replacing arguably broken (by some definition) Is there any reason to think that it ever actually worked in any way? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 11:23 AM, Jim Fulton j...@zope.com wrote: On Thu, Oct 17, 2013 at 11:20 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 11:56, Donald Stufft don...@stufft.io wrote: Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - You're proposing replacing arguably broken (by some definition) Is there any reason to think that it ever actually worked in any way? Depends what you mean by worked, it does nothing except tell users what they need available to ``import``. It doesn't tell them how to get that or what provides it. As far as this piece of metadata is concerned requires xml can be satisfied by ``touch xml.py``. So it works in that it does what it was originally intended to do, it's just that what it was originally intended to do is backwards and useless. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton - 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] Deprecate and Block requires/provides
On Thu, Oct 17, 2013 at 11:26 AM, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:23 AM, Jim Fulton j...@zope.com wrote: On Thu, Oct 17, 2013 at 11:20 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 11:56, Donald Stufft don...@stufft.io wrote: Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - You're proposing replacing arguably broken (by some definition) Is there any reason to think that it ever actually worked in any way? Depends what you mean by worked, it does nothing except tell users what they need available to ``import``. It doesn't tell them how to get that or what provides it. As far as this piece of metadata is concerned requires xml can be satisfied by ``touch xml.py``. So it works in that it does what it was originally intended to do, it's just that what it was originally intended to do is backwards and useless. I'm 92% sure it was intended to support automated dependency management, but then setuptools went in a different (better) direction. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 11:29 AM, Jim Fulton j...@zope.com wrote: I'm 92% sure it was intended to support automated dependency management, but then setuptools went in a different (better) direction. Hmm, that's entirely possible! I was around back then so i'm taking the intent from the PEP. - 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] Deprecate and Block requires/provides
On Oct 17, 2013, at 11:20 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 11:56, Donald Stufft don...@stufft.io wrote: Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - You're proposing replacing arguably broken (by some definition) with actually broken (no longer works). That's not an acceptable trade-off. I'm replacing Arguably broken for a small percentage of people with actually broken and easily fixed for a small percentage of people with no longer confusing for a large number of people. Of those people it would turn into actually broken a number of them are using it in a broken fashion and it's simply waiting for them to try and use it with a name that doesn't match an importable module for them to have it actually break for them regardless. Packaging is confusing enough without leaving foot guns littered through it. Packaging is confusing enough without breaking people's stuff! (Replacing a foot gun with actually shooting people's feet off if we're going to stick with the metaphor…) As I said above, breaking it for a small number of people to simplify it for the larger group. By this rationale Python 3 should never have happened. Replacing Packaging with Unicode. Michael On Oct 17, 2013, at 6:04 AM, Nick Coghlan ncogh...@gmail.com wrote: Don't break things when they don't pose an immediate security threat (and sometimes not even then) :) ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html - 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] Deprecate and Block requires/provides
On 18 October 2013 00:24, Erik Bray erik.m.b...@gmail.com wrote: On Thu, Oct 17, 2013 at 9:53 AM, Nick Coghlan ncogh...@gmail.com wrote: Yes, but breaking these users' uploads is not the way to do that. That's an incredibly user hostile step to take, and the problem doesn't even come close to justifying breaking even a not-really-working process (since you can work around the current breakage by manually installing the dependencies - you can't work around an inability to upload without making changes to your code). +1 I can imagine that from many users' perspectives you're doing it wrong isn't even true. The docs for distutils *still* read: Dependencies on other Python modules and packages can be specified by supplying the requires keyword argument to setup() and A package can declare that it obsoletes other packages using the obsoletes keyword argument and nowhere does it read but these keywords are broken and obsolete as of some obscure PEP and you're wrong to have used them. Indeed - the metadata PEPs really aren't aimed at end users. Until something is marked as deprecated in the CPython docs, and actually deprecated in the standard library, it isn't really deprecated :) We can at least do a documented deprecation in the CPython docs when we're implementing the PEP 453 documentation updates (I'll hopefully get the Windows path changes in this weekend sometime, and after that it should finally be ready for MvL's formal pronouncement) Cheers, Nick. If you really wanted to push them towards fixing their releases, you could always have PyPI send them an email saying something like: Hi, an automated scan of PyPI has shown that you're currently uploading metadata that uses the obsolete module dependency fields defined by distutils. These fields aren't actually checked by automated installation tools like pip, so if you're attempting to indicate that your project depends on other PyPI projects, this mechanism doesn't actually work to achieve that. At some point in the future, PyPI may disallow use of these fields entirely, so if you'd like to declare your dependencies in a way that automated tools can process, you may want to look at using the dependency declaration features in setuptools rather than using plain distutils. I was just going to ask--why not at least try to e-mail the maintainers of those packages? If they're unreachable to begin with then I'm a little less concerned. But at least give those who might care a direct heads up about where things are going. Then when the inevitable complaints do come in at least you've covered your ass :) Best, Erik -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote: Indeed - the metadata PEPs really aren't aimed at end users. Until something is marked as deprecated in the CPython docs, and actually deprecated in the standard library, it isn't really deprecated :) We can at least do a documented deprecation in the CPython docs when we're implementing the PEP 453 documentation updates (I'll hopefully get the Windows path changes in this weekend sometime, and after that it should finally be ready for MvL's formal pronouncement) Ironically the documentation shows how confusing it is because for someone new coming into packaging that documentation reads like this is what you put in in order to depend on other things. I would challenge anyone to write docs that aren't confusing that actually explains what requires actually does. So again I ask what I need to do to deprecate and remove requires, provides, obsoletes. Do I need to make a PEP? Do I need to make a bug tracker issue and a patch? What's the path forward. Can we at least agree that these can removed? obsoletes_dist - Never been used, never been implemented besides in Distutils2 requires_external - Used 9 times by 1 project, never been implemented outside of Distutils2 requires_python - Used 61 times, never been implemented outside of Distutils2 These either have a different method of supporting them in PEP426 (and thus keeping around two ways of doing the same thing is confusing, especially when it was never formally implemented) or were omitted completely. - 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] Deprecate and Block requires/provides
On 17 October 2013 16:23, Jim Fulton j...@zope.com wrote: On Thu, Oct 17, 2013 at 11:20 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 11:56, Donald Stufft don...@stufft.io wrote: Arguably it's already broken. I've had to explain to a number of people that it won't cause their dependencies to install. I think its way more user friendly to tell them up front then to confuse them when it doesn't work or when it appears to work but they get an error from a - You're proposing replacing arguably broken (by some definition) Is there any reason to think that it ever actually worked in any way? Package upload certainly worked, and that is what is going to be broken. Michael Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. - 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] Deprecate and Block requires/provides
On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. What about emitting a warning on upload/download for deprecated metadata and a warning on the PyPI page for the distribution? I don't know whether it's possible to implement that server side or if it would only apply to newer versions of distutils/setuptools etc. but it would give people who are still uploading sdists with this metadata a chance to make the fix in their own time rather than suddenly being unable to release updates. Cheers, Oscar ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On 18 October 2013 01:45, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote: Indeed - the metadata PEPs really aren't aimed at end users. Until something is marked as deprecated in the CPython docs, and actually deprecated in the standard library, it isn't really deprecated :) We can at least do a documented deprecation in the CPython docs when we're implementing the PEP 453 documentation updates (I'll hopefully get the Windows path changes in this weekend sometime, and after that it should finally be ready for MvL's formal pronouncement) Ironically the documentation shows how confusing it is because for someone new coming into packaging that documentation reads like this is what you put in in order to depend on other things. I would challenge anyone to write docs that aren't confusing that actually explains what requires actually does. The docs don't have to explain what it does, they have to explain that it's obsolete and shouldn't be used. Deprecating it in the metadata PEPs isn't enough. So again I ask what I need to do to deprecate and remove requires, provides, obsoletes. Do I need to make a PEP? Do I need to make a bug tracker issue and a patch? What's the path forward. The docs changes can probably be done as part of the PEP 453 docs updates. Emitting a deprecation warning in 3.4+ would need a patch on the CPython issue tracker. Can we at least agree that these can removed? obsoletes_dist - Never been used, never been implemented besides in Distutils2 requires_external - Used 9 times by 1 project, never been implemented outside of Distutils2 requires_python - Used 61 times, never been implemented outside of Distutils2 These either have a different method of supporting them in PEP426 (and thus keeping around two ways of doing the same thing is confusing, especially when it was never formally implemented) or were omitted completely. Sure, but what's the hurry? Is it just a matter of wanting to be able to leave them out of the Warehouse data model? As I stated earlier, I'm essentially OK with PyPI rejecting these with a clear error message and a pointer towards setuptools for *new* projects. I'm only averse to breaking them for projects that already have these populated in at least one release, and upload a new release that still includes them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 12:03 PM, Nick Coghlan ncogh...@gmail.com wrote: On 18 October 2013 01:45, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:36 AM, Nick Coghlan ncogh...@gmail.com wrote: Indeed - the metadata PEPs really aren't aimed at end users. Until something is marked as deprecated in the CPython docs, and actually deprecated in the standard library, it isn't really deprecated :) We can at least do a documented deprecation in the CPython docs when we're implementing the PEP 453 documentation updates (I'll hopefully get the Windows path changes in this weekend sometime, and after that it should finally be ready for MvL's formal pronouncement) Ironically the documentation shows how confusing it is because for someone new coming into packaging that documentation reads like this is what you put in in order to depend on other things. I would challenge anyone to write docs that aren't confusing that actually explains what requires actually does. The docs don't have to explain what it does, they have to explain that it's obsolete and shouldn't be used. Deprecating it in the metadata PEPs isn't enough. I meant supporting the viewpoint that these fields are confusing, not supporting that they've been deprecated. So again I ask what I need to do to deprecate and remove requires, provides, obsoletes. Do I need to make a PEP? Do I need to make a bug tracker issue and a patch? What's the path forward. The docs changes can probably be done as part of the PEP 453 docs updates. Emitting a deprecation warning in 3.4+ would need a patch on the CPython issue tracker. Distutils already accepts arbitrary keyword values and prints a warning so I think all that would need to be done is to remove them and let the regular machinery take care of it. I can work up a patch for that. Can we at least agree that these can removed? obsoletes_dist - Never been used, never been implemented besides in Distutils2 requires_external - Used 9 times by 1 project, never been implemented outside of Distutils2 requires_python - Used 61 times, never been implemented outside of Distutils2 These either have a different method of supporting them in PEP426 (and thus keeping around two ways of doing the same thing is confusing, especially when it was never formally implemented) or were omitted completely. Sure, but what's the hurry? Is it just a matter of wanting to be able to leave them out of the Warehouse data model? The hurry on these is less a hurry and more wanting to clear them out to prevent confusion. Warehouse is backed by the same schema that PyPI itself uses. If nobody (or practically nobody) is using them there's very little benefit to waiting to remove them. Cleaning up the database to try and remove some of the bit rot, bad ideas, deprecated and removed features is an ongoing process i've been engaged in. This is the area I was working on this morning. So it can wait, but I don't see a need to wait on these fields which will help clean up the DB. In this case when I came across these I thought about it and realized that these fields only really exist to confuse people and they should probably be removed out right. As I stated earlier, I'm essentially OK with PyPI rejecting these with a clear error message and a pointer towards setuptools for *new* projects. I'm only averse to breaking them for projects that already have these populated in at least one release, and upload a new release that still includes them. Are you fine with PyPI just discarding these pieces of metadata? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia - 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] Deprecate and Block requires/provides
On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. Fine with me. Michael - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecate and Block requires/provides
On Oct 17, 2013, at 9:26 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. My vote on this whole thing in the general context of how to handle deprecating metadata fields * Email anyone using deprecated metadata at the time of deprecation (or now, in the case of this stuff) * Deprecation would follow a somewhat normal arc: * Initially it is just marked as deprecated in the docs (pending deprecation phase). * One major release (which is fuzzy in this case, but 6-12 months) later it goes to dev null on input and is removed from all output. * One major release later it is a fatal error. Having this whole schedule formalized will help everyone to know how we evolve the metadata spec, and because it is key-value pairs we have some wiggle room to sometimes ignore certain keys or treat them as opaque blobs (a la HTTP/MIME headers). In the case of this instance, I would say we should do the email and dev-null-ing immediately and then just pick up as normal and in 6-12 months (whatever we decide, not that it should actually be an ill-defined time period) it becomes a fatal error. --Noah 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] Deprecate and Block requires/provides
On Oct 17, 2013, at 2:33 PM, Noah Kantrowitz n...@coderanger.net wrote: On Oct 17, 2013, at 9:26 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. My vote on this whole thing in the general context of how to handle deprecating metadata fields * Email anyone using deprecated metadata at the time of deprecation (or now, in the case of this stuff) * Deprecation would follow a somewhat normal arc: * Initially it is just marked as deprecated in the docs (pending deprecation phase). * One major release (which is fuzzy in this case, but 6-12 months) later it goes to dev null on input and is removed from all output. * One major release later it is a fatal error. Having this whole schedule formalized will help everyone to know how we evolve the metadata spec, and because it is key-value pairs we have some wiggle room to sometimes ignore certain keys or treat them as opaque blobs (a la HTTP/MIME headers). In the case of this instance, I would say we should do the email and dev-null-ing immediately and then just pick up as normal and in 6-12 months (whatever we decide, not that it should actually be an ill-defined time period) it becomes a fatal error. --Noah ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig This sounds reasonable to me. - 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] Deprecate and Block requires/provides
On 18 Oct 2013 04:48, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 2:33 PM, Noah Kantrowitz n...@coderanger.net wrote: On Oct 17, 2013, at 9:26 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. My vote on this whole thing in the general context of how to handle deprecating metadata fields * Email anyone using deprecated metadata at the time of deprecation (or now, in the case of this stuff) * Deprecation would follow a somewhat normal arc: * Initially it is just marked as deprecated in the docs (pending deprecation phase). * One major release (which is fuzzy in this case, but 6-12 months) later it goes to dev null on input and is removed from all output. * One major release later it is a fatal error. Having this whole schedule formalized will help everyone to know how we evolve the metadata spec, and because it is key-value pairs we have some wiggle room to sometimes ignore certain keys or treat them as opaque blobs (a la HTTP/MIME headers). In the case of this instance, I would say we should do the email and dev-null-ing immediately and then just pick up as normal and in 6-12 months (whatever we decide, not that it should actually be an ill-defined time period) it becomes a fatal error. --Noah ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig This sounds reasonable to me. And to me. A general Evolution of PyPI APIs process PEP could be a very helpful thing to avoid having to rehash this discussion for every change :) Given that PyPI doesn't have releases as such, perhaps we could tie this to the feature release cadence of pip? And officially recommend twine as the upload tool over using distutils directly? (Is twine ready for that at this point?) The only other thing I would add is that when previous output is /dev/null'ed we may want to have a placeholder for a while with a link to an explanation for the removal. Cheers, Nick. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] Deprecate and Block requires/provides
On Oct 17, 2013, at 6:50 PM, Nick Coghlan ncogh...@gmail.com wrote: And to me. A general Evolution of PyPI APIs process PEP could be a very helpful thing to avoid having to rehash this discussion for every change :) PEPapolza Given that PyPI doesn't have releases as such, perhaps we could tie this to the feature release cadence of pip? And officially recommend twine as the upload tool over using distutils directly? (Is twine ready for that at this point?) Possibly, but I think it probably makes more sense to just do date based. Individual proposals can include special casings that depend on a release of a piece of tooling if it makes sense for that proposal. The only other thing I would add is that when previous output is /dev/null'ed we may want to have a placeholder for a while with a link to an explanation for the removal. A placeholder where? On the PyPI UX or something? - 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] Deprecate and Block requires/provides
On Oct 17, 2013, at 3:50 PM, Nick Coghlan ncogh...@gmail.com wrote: On 18 Oct 2013 04:48, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 2:33 PM, Noah Kantrowitz n...@coderanger.net wrote: On Oct 17, 2013, at 9:26 AM, Michael Foord fuzzy...@gmail.com wrote: On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently gets sent to /dev/null in order to not break uploads for what would have affected roughly 4% of the total new releases on PyPI in 2013. My vote on this whole thing in the general context of how to handle deprecating metadata fields * Email anyone using deprecated metadata at the time of deprecation (or now, in the case of this stuff) * Deprecation would follow a somewhat normal arc: * Initially it is just marked as deprecated in the docs (pending deprecation phase). * One major release (which is fuzzy in this case, but 6-12 months) later it goes to dev null on input and is removed from all output. * One major release later it is a fatal error. Having this whole schedule formalized will help everyone to know how we evolve the metadata spec, and because it is key-value pairs we have some wiggle room to sometimes ignore certain keys or treat them as opaque blobs (a la HTTP/MIME headers). In the case of this instance, I would say we should do the email and dev-null-ing immediately and then just pick up as normal and in 6-12 months (whatever we decide, not that it should actually be an ill-defined time period) it becomes a fatal error. --Noah ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig This sounds reasonable to me. And to me. A general Evolution of PyPI APIs process PEP could be a very helpful thing to avoid having to rehash this discussion for every change :) +1, especially because the process is asymmetric, pip needs to accept and silently ignore unknown metadata fields indefinitely. --Noah 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] Deprecate and Block requires/provides
On 18 Oct 2013 08:55, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 6:50 PM, Nick Coghlan ncogh...@gmail.com wrote: And to me. A general Evolution of PyPI APIs process PEP could be a very helpful thing to avoid having to rehash this discussion for every change :) PEPapolza One PEP, two PEP, three PEP, more PEP :) It occurs to me the numbering for new process PEPs is different from normal. Still, just a matter of looking at PEP 0 to pick the right subrange. Given that PyPI doesn't have releases as such, perhaps we could tie this to the feature release cadence of pip? And officially recommend twine as the upload tool over using distutils directly? (Is twine ready for that at this point?) Possibly, but I think it probably makes more sense to just do date based. Individual proposals can include special casings that depend on a release of a piece of tooling if it makes sense for that proposal. That works, too. The only other thing I would add is that when previous output is /dev/null'ed we may want to have a placeholder for a while with a link to an explanation for the removal. A placeholder where? On the PyPI UX or something? Yeah, I was thinking of the part at the bottom of the package info page that currently displays this metadata. Cheers, Nick. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
