PyPi not allowing duplicate filenames
Hi all, PyPi does not allow duplicate file names -- this makes lots of sense, because you really don't want people to go to PyPi one day and grab a file, and then go there another day, grab a file with exactly the same name, and have it be a different file. However.... We are all too human, and make mistakes when doing a release. All to often someone pushed a broken file up to PyPi, often realizes it pretty quickly -- before anyone has a chance to even download it (or only the dev team as, for testing...). In fact, I was in a sprint last summer, and we decided to push our package up to PyPi -- granted, we were all careless amateurish noobs, but we ended up making I think 4! minor version bumps because we had done something stupid in the sdist. Also -- the latest numpy release got caught in this, too: """ * We ran into a problem with pipy not allowing reuse of filenames and a resulting proliferation of *.*.*.postN releases. Not only were the names getting out of hand, some packages were unable to work with the postN suffix. """ So -- I propose that PyPi allow projects to replace existing files if they REALLY REALLY want to. You should have to jump through all sorts of hoops, and make it really clear that it is a BAD IDEA in the general case, but it'd be good to have it be possible. After all -- PyPi does not take on responsibility for anything else about what's in those packages, and Python itself is all about "we're all consenting adults here" I suppose we could even put in some heuristics about how long the file as been there, how many times it's been downloaded, etc. Just a thought.....I really hate systems that don't let me roll back mistakes, even when I discover them almost immediately... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 2015-10-14 09:43:25 -0700 (-0700), Chris Barker wrote: [...]
I propose that PyPi allow projects to replace existing files if they REALLY REALLY want to.
You should have to jump through all sorts of hoops, and make it really clear that it is a BAD IDEA in the general case, but it'd be good to have it be possible. [...]
It used to be possible. If that possibility returns, I'm not looking forward to more of the bugs I used to semi-regularly file explaining to package authors why their assumptions about the safety of silently replacing their broken releases were flawed. -- Jeremy Stanley
On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <chris.barker@noaa.gov> wrote:
some packages were unable to work with the postN suffix.
Can you elaborate a bit more here? Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
On Oct 14, 2015 10:04 AM, "Ionel Cristian Mărieș" <contact@ionelmc.ro> wrote:
On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <chris.barker@noaa.gov>
wrote:
some packages were unable to work with the postN suffix.
Can you elaborate a bit more here?
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.) IIUC, the specific problems numpy ran into that caused the creation of .postN releases were: - oops, didn't sign the uploads, re-upload identical file with proper signature attached -> not allowed. (I'm not sure if these were embedded or detached signatures. Either way it'd be nice if pypi allowed it, but for embedded signatures in particular I can see how this might be a hassle.) - our OS X maintainer tried to use twine to upload OS X wheels for the existing release; instead it created a new release. Not sure if a bug was filed on twine, but if not then one probably should be. As a workaround our release docs now say "always upload wheels by hand using the web interface, never use setup.py upload or twine". My feeling is that pypi is correct to disallow the mutation of releases once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step. CC'ing the release manager and OS X maintainer in question, in case I got something wrong or more details are wanted... -n
On Oct 14, 2015 12:05 PM, "Ionel Cristian Mărieș" <contact@ionelmc.ro> wrote:
On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <chris.barker@noaa.gov>
wrote:
some packages were unable to work with the postN suffix.
Can you elaborate a bit more here?
AFAIU, the community best practice here is to issue a new release with a bumped version number/pre/post/releasecode. * https://www.python.org/dev/peps/pep-0440/#version-scheme * https://github.com/peritus/bumpversion * http://docs.openstack.org/developer/pbr/semver.html#changes-vs-semver-2-0 MAJOR.MINOR.PATCH The reasons for this are many: * HTTP caches * local pip/buildout pkg caches * it is actually a different resource, with a different URI (repo,pkg,version,[pkgtype,platform,buildtags]) because it contains different files
Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
FYI, this was discussed recently here too: https://github.com/pypa/packaging-problems/issues/74 On Wed, Oct 14, 2015 at 1:39 PM, Wes Turner <wes.turner@gmail.com> wrote:
On Oct 14, 2015 12:05 PM, "Ionel Cristian Mărieș" <contact@ionelmc.ro> wrote:
On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <chris.barker@noaa.gov>
wrote:
some packages were unable to work with the postN suffix.
Can you elaborate a bit more here?
AFAIU, the community best practice here is to issue a new release with a bumped version number/pre/post/releasecode.
* https://www.python.org/dev/peps/pep-0440/#version-scheme * https://github.com/peritus/bumpversion * http://docs.openstack.org/developer/pbr/semver.html#changes-vs-semver-2-0
MAJOR.MINOR.PATCH
The reasons for this are many: * HTTP caches * local pip/buildout pkg caches * it is actually a different resource, with a different URI (repo,pkg,version,[pkgtype,platform,buildtags]) because it contains different files
Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
_______________________________________________ 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
On October 14, 2015 at 1:37:05 PM, Nathaniel Smith (njs@pobox.com) wrote: On Oct 14, 2015 10:04 AM, "Ionel Cristian Mărieș" <contact@ionelmc.ro> wrote:
On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <chris.barker@noaa.gov> wrote:
some packages were unable to work with the postN suffix.
Can you elaborate a bit more here?
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.) https://github.com/pypa/packaging It’s what both pip and setuptools use (though we embed it, but it’s fine to depend on it too). IIUC, the specific problems numpy ran into that caused the creation of .postN releases were: - oops, didn't sign the uploads, re-upload identical file with proper signature attached -> not allowed. (I'm not sure if these were embedded or detached signatures. Either way it'd be nice if pypi allowed it, but for embedded signatures in particular I can see how this might be a hassle.) I don’t think we allow embedded signatures, it would be reasonable to allow uploading detached signatures after the fact though. - our OS X maintainer tried to use twine to upload OS X wheels for the existing release; instead it created a new release. Not sure if a bug was filed on twine, but if not then one probably should be. As a workaround our release docs now say "always upload wheels by hand using the web interface, never use setup.py upload or twine". This shouldn’t create a new release unless you’ve changed the version number (including adding post releases). If you can reproduce on Test PyPI I can fix it. My feeling is that pypi is correct to disallow the mutation of releases once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step. The ergonomics of it is pretty bad. Once we kill PyPI legacy and Warehouse is the thing we’re using, improving things like that will be a lot simpler. CC'ing the release manager and OS X maintainer in question, in case I got something wrong or more details are wanted... -n _______________________________________________ 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
On Oct 14, 2015 11:12 AM, "Donald Stufft" <donald@stufft.io> wrote:
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when
[...] they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine
to depend on it too). That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
IIUC, the specific problems numpy ran into that caused the creation of
.postN releases were:
- oops, didn't sign the uploads, re-upload identical file with proper signature attached -> not allowed. (I'm not sure if these were embedded or detached signatures. Either way it'd be nice if pypi allowed it, but for embedded signatures in particular I can see how this might be a hassle.)
I don’t think we allow embedded signatures, it would be reasonable to allow uploading detached signatures after the fact though.
- our OS X maintainer tried to use twine to upload OS X wheels for the
existing release; instead it created a new release. Not sure if a bug was filed on twine, but if not then one probably should be. As a workaround our release docs now say "always upload wheels by hand using the web interface, never use setup.py upload or twine".
This shouldn’t create a new release unless you’ve changed the version number (including adding post releases). If you can reproduce on Test PyPI I can fix it.
Matthew? Any thoughts? -n
On October 14, 2015 at 2:25:31 PM, Nathaniel Smith (njs@pobox.com) wrote:
On Oct 14, 2015 11:12 AM, "Donald Stufft" wrote:
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when
[...] they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine
to depend on it too).
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
I suspect it’d be trivial to relicense it. There’s a total of 6 contributors and I think I know how to get ahold of all of them.
IIUC, the specific problems numpy ran into that caused the creation of
.postN releases were:
- oops, didn't sign the uploads, re-upload identical file with proper signature attached -> not allowed. (I'm not sure if these were embedded or detached signatures. Either way it'd be nice if pypi allowed it, but for embedded signatures in particular I can see how this might be a hassle.)
I don’t think we allow embedded signatures, it would be reasonable to allow uploading detached signatures after the fact though.
- our OS X maintainer tried to use twine to upload OS X wheels for the
existing release; instead it created a new release. Not sure if a bug was filed on twine, but if not then one probably should be. As a workaround our release docs now say "always upload wheels by hand using the web interface, never use setup.py upload or twine".
This shouldn’t create a new release unless you’ve changed the version number (including adding post releases). If you can reproduce on Test PyPI I can fix it.
Matthew? Any thoughts?
-n
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On October 14, 2015 at 2:27:40 PM, Donald Stufft (donald@stufft.io) wrote:
On October 14, 2015 at 2:25:31 PM, Nathaniel Smith (njs@pobox.com) wrote:
On Oct 14, 2015 11:12 AM, "Donald Stufft" wrote:
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when
[...] they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine
to depend on it too).
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
I suspect it’d be trivial to relicense it. There’s a total of 6 contributors and I think I know how to get ahold of all of them.
https://github.com/pypa/packaging/issues/42 ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 14 October 2015 at 19:27, Donald Stufft <donald@stufft.io> wrote:
I suspect it’d be trivial to relicense it. There’s a total of 6 contributors and I think I know how to get ahold of all of them.
I only contributed a tiny bit, but I'm happy for you to relicense if you want to. Paul
Hi, On Wed, Oct 14, 2015 at 11:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 14, 2015 11:12 AM, "Donald Stufft" <donald@stufft.io> wrote:
[...]
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine to depend on it too).
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
IIUC, the specific problems numpy ran into that caused the creation of .postN releases were: - oops, didn't sign the uploads, re-upload identical file with proper signature attached -> not allowed. (I'm not sure if these were embedded or detached signatures. Either way it'd be nice if pypi allowed it, but for embedded signatures in particular I can see how this might be a hassle.)
I don’t think we allow embedded signatures, it would be reasonable to allow uploading detached signatures after the fact though.
- our OS X maintainer tried to use twine to upload OS X wheels for the existing release; instead it created a new release. Not sure if a bug was filed on twine, but if not then one probably should be. As a workaround our release docs now say "always upload wheels by hand using the web interface, never use setup.py upload or twine".
This shouldn’t create a new release unless you’ve changed the version number (including adding post releases). If you can reproduce on Test PyPI I can fix it.
Matthew? Any thoughts?
Sorry - I'm not sure whether y'all are surprised by the behavior of twine in this situation. Specifically, the situation was: * There was a release on pypi was labeled 1.10.0 : https://pypi.python.org/pypi/numpy/1.10.0; * The source archives that Chuck uploaded were from code that gave a version string of '1.10.0.post2'; * I built wheels from this code, that had this version encoded in the filename - e.g. http://wheels.scikit-image.org/numpy-1.10.0.post2-cp27-none-macosx_10_6_inte... ; * I used `twine upload http://wheels.scikit-image.org/numpy-1.10.0.post2-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl` etc to upload these. When I did this, pypi created a new release called https://pypi.python.org/pypi/numpy/1.10.0.post2 and put the wheels there. I'm guessing that this is what y'all expected? Best, Matthew
On 15 October 2015 at 07:27, Donald Stufft <donald@stufft.io> wrote:
On October 14, 2015 at 2:25:31 PM, Nathaniel Smith (njs@pobox.com) wrote:
On Oct 14, 2015 11:12 AM, "Donald Stufft" wrote:
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when
[...] they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine
to depend on it too).
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
I suspect it’d be trivial to relicense it. There’s a total of 6 contributors and I think I know how to get ahold of all of them.
Presumably to MIT + ApacheV2 ? -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On October 14, 2015 at 3:05:57 PM, Robert Collins (robertc@robertcollins.net) wrote:
On 15 October 2015 at 07:27, Donald Stufft wrote:
On October 14, 2015 at 2:25:31 PM, Nathaniel Smith (njs@pobox.com) wrote:
On Oct 14, 2015 11:12 AM, "Donald Stufft" wrote:
Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when
[...] they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine
to depend on it too).
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
I suspect it’d be trivial to relicense it. There’s a total of 6 contributors and I think I know how to get ahold of all of them.
Presumably to MIT + ApacheV2 ?
2 Clause BSD and Apache v2.0. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Oct 14, 2015, at 10:36 AM, Nathaniel Smith <njs@pobox.com> wrote:
My feeling is that pypi is correct to disallow the mutation of releases once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step.
IMHO it would be really neat if 'pip' could authenticate to PyPI, and the authentication could affect package visibility, so that you could end-to-end test 'pip install foo' and ensure that you get what you expect before pushing the go-live switch. -glyph
On 15 October 2015 at 09:55, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Oct 14, 2015, at 10:36 AM, Nathaniel Smith <njs@pobox.com> wrote:
My feeling is that pypi is correct to disallow the mutation of releases once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step.
IMHO it would be really neat if 'pip' could authenticate to PyPI, and the authentication could affect package visibility, so that you could end-to-end test 'pip install foo' and ensure that you get what you expect before pushing the go-live switch.
And if its bust for you? Surely testpypi is equally good and its an existing solution? -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On Oct 14, 2015, at 4:55 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Oct 14, 2015, at 10:36 AM, Nathaniel Smith <njs@pobox.com> wrote:
My feeling is that pypi is correct to disallow the mutation of releases once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step.
IMHO it would be really neat if 'pip' could authenticate to PyPI, and the authentication could affect package visibility, so that you could end-to-end test 'pip install foo' and ensure that you get what you expect before pushing the go-live switch.
Can't be done without a pretty huge regression in uptime and speed.
On Oct 14, 2015 1:55 PM, "Glyph Lefkowitz" <glyph@twistedmatrix.com> wrote:
On Oct 14, 2015, at 10:36 AM, Nathaniel Smith <njs@pobox.com> wrote:
My feeling is that pypi is correct to disallow the mutation of releases
once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step.
IMHO it would be really neat if 'pip' could authenticate to PyPI, and the
authentication could affect package visibility, so that you could end-to-end test 'pip install foo' and ensure that you get what you expect before pushing the go-live switch. The slick way to do this would be to provide a private index URL that gives you a view of what pypi would look like after your release goes live, and could be used like pip install --index-url https://pypi.python.org/tmp/foo/acd1538afe267/ foo That way you skip all the issues of adding an authentication system to pip, plus get a URL that you can pass around to other people ("hey #twisted, can someone who's on Windows test the new release? Just type: ...") You'd want to expire these after some time to prevent them being abused as private package indices for proprietary software, but that's easy enough. @Donald: is there somewhere we should be filing these warehouse wish list things so they don't get lost? :-) -n
On October 14, 2015 at 5:17:42 PM, Nathaniel Smith (njs@pobox.com) wrote:
@Donald: is there somewhere we should be filing these warehouse wish list things so they don't get lost? :-)
https://github.com/pypa/warehouse/issues ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Nathaniel Smith <njs@pobox.com> writes:
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
I'm not sure what the claim is here, but it seems false to me. Apache License 2.0 permits a derived work to be released under a different license (even a non-free license). See Apache License 2.0 §4. So a work BAR can be released under GNU GPL (e.g. “version 3 or later”) that derives from work FOO released under Apache License 2.0. The GNU GPL version 3 allows combination with other works with different license conditions, provided those conditions don't impose further restrictions on recipients. See GNU GPL v3 §7, §10, §12. (GPL v2 has different wording with similar effect.) Apache License 2.0 imposes no additional reastrictions on the recipient of a work licensed under GNU GPL v3. So that meets the conditions of both. FOO as a distinct work retains its license conditions, and all recipients of FOO or BAR must comply with its conditions. The work BAR as a whole carries the GNU GPL version (for example) 3 conditions, and all recipients of BAR must comply with its conditions. The two licenses are compatible, as far as I can see. The effective result is a work BAR, licensed as free software under GPL version (e.g.) 3 or later. Does that not match your understanding? Have I misunderstood your claim? -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney
On Oct 14, 2015 10:02 PM, "Ben Finney" <ben+python@benfinney.id.au> wrote:
Nathaniel Smith <njs@pobox.com> writes:
That's under Apache 2, so it can't be used by GPLv2 packages, or any package that might be used by GPLv2 packages.
I'm not sure what the claim is here, but it seems false to me.
Apache License 2.0 permits a derived work to be released under a different license (even a non-free license). See Apache License 2.0 §4.
The FSF believes that Apache 2 is incompatible with GPLv2 (but v3 is OK), IIRC because of some technicalities involving the patent provisions. (I'm sure you can google up infinite detail if you want -- I'm just the messenger.) There are others who disagree and think it's fine, but no one wants murkiness when it comes to licenses, so people with BSD or GPLv2 projects are unlikely to risk incorporating code from a project under Apache 2. -n
Ben Finney <ben+python@benfinney.id.au> writes:
Apache License 2.0 imposes no additional reastrictions on the recipient of a work licensed under GNU GPL v3. So that meets the conditions of both.
Apache License 2.0 does impose further restrictions not found in GPL v2 though. Sorry for the confusion. Nathaniel Smith <njs@pobox.com> writes:
The FSF believes that Apache 2 is incompatible with GPLv2 (but v3 is OK)
Yes, I'd neglected that. <URL:https://gnu.org/licenses/license-list.html#apache2> -- \ “My house is made out of balsa wood, so when I want to scare | `\ the neighborhood kids I lift it over my head and tell them to | _o__) get out of my yard or I'll throw it at them.” —Steven Wright | Ben Finney
On Wed, Oct 14, 2015 at 3:02 PM, Donald Stufft <donald@stufft.io> wrote:
On October 14, 2015 at 5:17:42 PM, Nathaniel Smith (njs@pobox.com) wrote:
@Donald: is there somewhere we should be filing these warehouse wish list things so they don't get lost? :-)
https://github.com/pypa/warehouse/issues/726 -- Nathaniel J. Smith -- http://vorpus.org
Right now, there are ways for package maintainers to test and share draft versions of their upcoming releases, but they cause friction and confusion. So we want to add staged releases -- a temporary state that a release can be in, where PyPI _has_ it and can evaluate it, but hasn't _published_ it yet. In 2015, Nathaniel Smith opened an issue https://github.com/pypa/warehouse/issues/726 saying:
it would be very nice if there where better ergonomics around package uploads -- in particular some way to upload a new release, and then take a look over it to double-check that everything is correct before you -- as a second step -- hit the button to make it "go live".
We have also variously called this idea "unpublished releases", "two-phase upload", "draft releases", and "package preview". This feature will unblock a LOT of stuff we want to do -- see https://wiki.python.org/psf/Fundable%20Packaging%20Improvements#Package_prev... for a list. Alan Velasco is now working on implementing this in Warehouse. Please comment on the GitHub issue or in the Discourse thread at https://discuss.python.org/t/feature-proposal-for-pypi-draft-releases/3903/ where he shares his proposal at length. He notes:
I’ll need your feedback by April 30th 2020 at which point I’ll proceed with the basis of what I know.
(Thread was: Re: [Distutils] PyPi not allowing duplicate filenames https://mail.python.org/archives/list/distutils-sig@python.org/message/S37OQ... ) -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
participants (13)
-
Ben Finney -
Chris Barker -
Dave Forgac -
Donald Stufft -
Glyph Lefkowitz -
Ionel Cristian Mărieș -
Jeremy Stanley -
Matthew Brett -
Nathaniel Smith -
Paul Moore -
Robert Collins -
Sumana Harihareswara -
Wes Turner