Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users who have already installed one
of the non-broken ones to upgrade again, even though they are not
Yes.
Seems to me the issues
Thanks for the confirmation that my interpretation was wrong. This
makes things a lot better :-)
More below...
On 29.09.2014 11:39, Nick Coghlan wrote:
On 29 Sep 2014 18:49, M.-A. Lemburg m...@egenix.com wrote:
You are missing out on cases, where the release process causes files to
be
On 30 Sep 2014 19:06, M.-A. Lemburg m...@egenix.com wrote:
You're regularly bringing up this argument.
Let's just be fair here: external hosting of packages has been made so
user unfriendly in recent pip releases, that this has pretty much
become a non-option for anyone who wants to create a
On 30 September 2014 10:06, M.-A. Lemburg m...@egenix.com wrote:
Let's just be fair here: external hosting of packages has been made so
user unfriendly in recent pip releases, that this has pretty much
become a non-option for anyone who wants to create a user friendly
package installation
On September 30, 2014 at 5:07:06 AM, M.-A. Lemburg (m...@egenix.com) wrote:
Thanks for the confirmation that my interpretation was wrong. This
makes things a lot better :-)
More below...
On 29.09.2014 11:39, Nick Coghlan wrote:
On 29 Sep 2014 18:49, M.-A. Lemburg wrote:
You are
On 30 September 2014 21:30, Donald Stufft don...@stufft.io wrote:
In pip 1.5.x (current latest release) people can add additional indexes (or
replace PyPI all together) on a per user basis. In pip 6.0 (next release) that
still exists, and in addition it also includes a global configuration file
On 2014-09-30 07:26:32 -0400 (-0400), Donald Stufft wrote:
[...]
I don’t personally believe it makes sense for a source
distribution to have a build number.
[...]
I'm becoming less and less convinced it actually *is* a source
distribution any more. My constant interaction with downstream Linux
On 2014-09-30 11:06:40 +0200 (+0200), M.-A. Lemburg wrote:
[...]
You're regularly bringing up this argument.
Let's just be fair here: external hosting of packages has been
made so user unfriendly in recent pip releases, that this has
pretty much become a non-option for anyone who wants to
On 30 September 2014 11:35, Robin Becker ro...@reportlab.com wrote:
What would be the objection to removing or nulling a release package that
had actual malware embedded in it some how. It seems reasonable to have some
last resort take down mechanism.
None at all. Removal is specifically still
On 29/09/2014 10:50, Nick Coghlan wrote:
On 29 Sep 2014 19:04, M.-A. Lemburg m...@egenix.com wrote:
Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users who have already installed
On 09/30/2014 08:41 AM, Nick Coghlan wrote:
Why is your setup.py sdist including autogenerated content? It
shouldn't be doing that.
Don't almost all sdists? At the very least egg-info is autogenerated,
MANIFEST usually is too.
Carl
___
Distutils-SIG
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
Installers and PyPI would then regard 3.1.4-1 as belonging to
release 3.1.4, but being a more current build as a distribution
file carrying 3.1.4 in its file name.
Please don't literally use 3.1.4-1. That will cause all kinds of havoc with
the
On 30 Sep 2014, at 17:35, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
Installers and PyPI would then regard 3.1.4-1 as belonging to
release 3.1.4, but being a more current build as a distribution
file carrying 3.1.4 in its file name.
Please
On 2014-09-30 09:22:29 -0600 (-0600), Carl Meyer wrote:
On 09/30/2014 08:41 AM, Nick Coghlan wrote:
Why is your setup.py sdist including autogenerated content? It
shouldn't be doing that.
Don't almost all sdists? At the very least egg-info is
autogenerated, MANIFEST usually is too.
On Sep 30, 2014, at 02:34 PM, Jeremy Stanley wrote:
I'm becoming less and less convinced it actually *is* a source
distribution any more. My constant interaction with downstream Linux
distro packagers shows a growing disinterest in consuming release
tarballs of software, that they would generally
On Sep 30, 2014, at 05:40 PM, Wichert Akkerman wrote:
Debian does allow 3.1.4-1-1. I forgot the exact rules, but I seem to remember
the package version is considered to start after the last dash. Debian will
also sort 3.1.4a after 3.1.4 unlike Python rules, so version “massaging”
might be
On 2014-09-30 12:07:23 -0400 (-0400), Barry Warsaw wrote:
We had a discussion about this at the recently concluded Debian
conference. There are folks who only want to use git tags as the
consumption point for Debian packages, but this opinion was not
the majority opinion.
Good to know. The
On Sep 30, 2014, at 04:25 PM, Jeremy Stanley wrote:
Good to know. The Debian Developer packaging the majority of the
projects I work on must be in that minority.
IIRC, the OpenStack packagers were probably the most prominent proponent of
release-from-tag.
Cheers,
-Barry
signature.asc
On 1 October 2014 04:40, Wichert Akkerman wich...@wiggy.net wrote:
On 30 Sep 2014, at 17:35, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
Installers and PyPI would then regard 3.1.4-1 as belonging to
release 3.1.4, but being a more current build as
On Sun, Sep 28, 2014 at 10:28 PM, Marius Gedminas mar...@pov.lt wrote:
On Sun, Sep 28, 2014 at 02:21:11PM -0700, Chris Jerdonek wrote:
Would this also affect the ability to update the readme information
for a version on PyPI (i.e. the information displayed on the default
home page generated by
On 28.09.2014 23:59, Donald Stufft wrote:
On Sep 28, 2014, at 5:36 PM, M.-A. Lemburg m...@egenix.com
mailto:m...@egenix.com wrote:
On 28.09.2014 21:31, Donald Stufft wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you
On 29 September 2014 09:46, M.-A. Lemburg m...@egenix.com wrote:
If I understand you correctly, you are essentially suggesting that it
becomes impossible to ever delete anything uploaded to PyPI, i.e.
turning PyPI into a WORM.
My understanding (I'm sure Donald will correct me if I'm wrong) is
On 29.09.2014 00:51, Nick Coghlan wrote:
On 29 Sep 2014 07:37, M.-A. Lemburg m...@egenix.com wrote:
-1.
It does happen that files need to be reuploaded because of a bug
in the release process and how people manage their code is really
*their* business, not that of PyPI.
FWIW, I am getting
On Mon, Sep 29, 2014 at 10:46 +0200, M.-A. Lemburg wrote:
On 28.09.2014 23:59, Donald Stufft wrote:
On Sep 28, 2014, at 5:36 PM, M.-A. Lemburg m...@egenix.com
mailto:m...@egenix.com wrote:
On 28.09.2014 21:31, Donald Stufft wrote:
Hello All!
I'd like to discuss the idea of
On 29 Sep 2014 18:49, M.-A. Lemburg m...@egenix.com wrote:
You are missing out on cases, where the release process causes files to
be omitted, human errors where packagers forget to apply changes to
e.g. documentation files, version files, change logs, etc., where
packagers want to add
On 29 Sep 2014 19:04, M.-A. Lemburg m...@egenix.com wrote:
Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users who have already installed one
of the non-broken ones to upgrade
On 29 Sep 2014 19:50, Nick Coghlan ncogh...@gmail.com wrote:
On 29 Sep 2014 19:04, M.-A. Lemburg m...@egenix.com wrote:
Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users
On Sep 29, 2014, at 6:01 AM, Nick Coghlan
ncogh...@gmail.commailto:ncogh...@gmail.com wrote:
On 29 Sep 2014 19:50, Nick Coghlan
ncogh...@gmail.commailto:ncogh...@gmail.com wrote:
On 29 Sep 2014 19:04, M.-A. Lemburg
m...@egenix.commailto:m...@egenix.com wrote:
Do you seriously want to
(Fixed quoting indent + some own comments)
On Mon, Sep 29, 2014 at 11:04 +, Donald Stufft wrote:
On Sep 29, 2014, at 6:01 AM, Nick Coghlan
ncogh...@gmail.commailto:ncogh...@gmail.com wrote:
On 29 Sep 2014 19:50, Nick Coghlan
ncogh...@gmail.commailto:ncogh...@gmail.com wrote:
On
On Sep 29, 2014, at 4:46 AM, M.-A. Lemburg
m...@egenix.commailto:m...@egenix.com wrote:
You are missing out on cases, where the release process causes files to
be omitted, human errors where packagers forget to apply changes to
e.g. documentation files, version files, change logs, etc., where
On 29 Sep 2014 21:04, Donald Stufft donald.stu...@rackspace.com wrote:
On Sep 29, 2014, at 6:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
One caveat on this: it would potentially be convenient to have a
release field in the wheel naming scheme, and adopt a similar approach
for other binary
On 29 Sep 2014 21:20, holger krekel hol...@merlinux.eu wrote:
(Fixed quoting indent + some own comments)
On Mon, Sep 29, 2014 at 11:04 +, Donald Stufft wrote:
On Sep 29, 2014, at 6:01 AM, Nick Coghlan ncogh...@gmail.commailto:
ncogh...@gmail.com wrote:
It's the silent substitution of
On 29 Sep 2014, at 13:58, Nick Coghlan ncogh...@gmail.com wrote:
Right, this is my perspective as well. The point that the wheel format
already includes a build ordering field was significant because that file
naming scheme has an official specification.
Other commands like bdist_egg,
On September 29, 2014 at 8:54:26 AM, Wichert Akkerman (wich...@wiggy.net) wrote:
On 29 Sep 2014, at 13:58, Nick Coghlan ncogh...@gmail.com wrote:
Right, this is my perspective as well. The point that the wheel format already
includes a build ordering field was significant because that file naming
On 29 Sep 2014, at 15:21, Donald Stufft don...@stufft.io wrote:
On September 29, 2014 at 8:54:26 AM, Wichert Akkerman (wich...@wiggy.net)
wrote:
On 29 Sep 2014, at 13:58, Nick Coghlan ncogh...@gmail.com wrote:
Right, this is my perspective as well. The point that the wheel format
already
On September 29, 2014 at 9:25:37 AM, Wichert Akkerman (wich...@wiggy.net) wrote:
On 29 Sep 2014, at 15:21, Donald Stufft don...@stufft.io wrote:
On September 29, 2014 at 8:54:26 AM, Wichert Akkerman (wich...@wiggy.net) wrote:
On 29 Sep 2014, at 13:58, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Sep 28, 2014 at 3:31 PM, Donald Stufft
donald.stu...@rackspace.com wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files.
...
+1
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG
On Sep 28, 2014, at 07:31 PM, Donald Stufft wrote:
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload
that file again with different contents. This would still allow deleting the
file or reuploading
On Mon, Sep 29, 2014 at 9:36 AM, Barry Warsaw ba...@python.org wrote:
On Sep 28, 2014, at 07:31 PM, Donald Stufft wrote:
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload
that file again with
On September 29, 2014 at 10:41:07 AM, Ian Cordasco (graffatcolmin...@gmail.com)
wrote:
On Mon, Sep 29, 2014 at 9:36 AM, Barry Warsaw ba...@python.org wrote:
On Sep 28, 2014, at 07:31 PM, Donald Stufft wrote:
I'd like to discuss the idea of moving PyPI to having immutable files. This
+1
On Sep 29, 2014 7:29 AM, Jim Fulton j...@zope.com wrote:
On Sun, Sep 28, 2014 at 3:31 PM, Donald Stufft
donald.stu...@rackspace.com wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files.
...
+1
Jim
--
Jim Fulton
On Sep 29, 2014, at 09:40 AM, Ian Cordasco wrote:
That's essentially what I see as the chief use-case for
testpypi.python.org. I don't think pypi.python.org needs to support
this as well. Simple is better than complex after all :)
Can we then make it easy to upload to testpypi via the cli?
On Mon, Sep 29, 2014 at 10:03 AM, Barry Warsaw ba...@python.org wrote:
On Sep 29, 2014, at 09:40 AM, Ian Cordasco wrote:
That's essentially what I see as the chief use-case for
testpypi.python.org. I don't think pypi.python.org needs to support
this as well. Simple is better than complex after
On September 29, 2014 at 11:04:42 AM, Barry Warsaw (ba...@python.org) wrote:
On Sep 29, 2014, at 09:40 AM, Ian Cordasco wrote:
That's essentially what I see as the chief use-case for
testpypi.python.org. I don't think pypi.python.org needs to support
this as well. Simple is better than
On 30 Sep 2014 00:43, Donald Stufft don...@stufft.io wrote:
Yea I don’t think PyPI needs anything for this, if someone wants to do it
they can use testpypi.python.org, or they can stand up a devpi instance
which offers a similar thing plus a lot more for a release process.
It occurs to me that
On 29 Sep 2014 22:09, Wichert Akkerman wich...@wiggy.net wrote:
On 29 Sep 2014, at 13:58, Nick Coghlan ncogh...@gmail.com wrote:
Right, this is my perspective as well. The point that the wheel format
already includes a build ordering field was significant because that file
naming scheme has an
On September 29, 2014 at 5:33:38 PM, Nick Coghlan (ncogh...@gmail.com) wrote:
On 30 Sep 2014 00:43, Donald Stufft wrote:
Yea I don’t think PyPI needs anything for this, if someone wants to do it
they can use testpypi.python.org, or they can stand up a devpi instance
which offers a similar
On 29 September 2014 23:16, Donald Stufft don...@stufft.io wrote:
It occurs to me that a devpi quickstart for OpenShift (or another PaaS's)
free tier could be useful - if a devpi instance is just for pre-release
testing of packages, then the free tier should accommodate it comfortably.
I'm
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload that
file again with different contents. This would still allow deleting the file or
reuploading it if the checksums match what was
Would this also affect the ability to update the readme information
for a version on PyPI (i.e. the information displayed on the default
home page generated by PyPI for the release) once the version has
already been uploaded to PyPI?
There are sometimes issues encountered with the display of that
On 09/28/2014 12:31 PM, Donald Stufft wrote:
I'd like to discuss the idea of moving PyPI to having immutable files.
Perhaps I'm missing something, but I already get errors if I try to reupload a
package with the same version number.
--
~Ethan~
___
On Sep 28, 2014, at 5:21 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote:
Would this also affect the ability to update the readme information
for a version on PyPI (i.e. the information displayed on the default
home page generated by PyPI for the release) once the version has
already
On Sep 28, 2014, at 5:21 PM, Ethan Furman et...@stoneleaf.us wrote:
On 09/28/2014 12:31 PM, Donald Stufft wrote:
I'd like to discuss the idea of moving PyPI to having immutable files.
Perhaps I'm missing something, but I already get errors if I try to reupload
a package with the same
The intent was always that files were immutable. The deleting loophole is
just something that I never got around to fixing.
+1 to fix that bug :)
On 29 September 2014 07:23, Donald Stufft don...@stufft.io wrote:
On Sep 28, 2014, at 5:21 PM, Ethan Furman et...@stoneleaf.us wrote:
On
On 09/28/2014 02:29 PM, Richard Jones wrote:
The intent was always that files were immutable. The deleting loophole is just
something that I never got around to fixing.
+1 to fix that bug :)
Agreed! :)
--
~Ethan~
___
Distutils-SIG maillist -
On 28.09.2014 21:31, Donald Stufft wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload that
file again with different contents. This would still allow deleting the file
or
Just to reiterate: from the beginning uploaded files were immutable, but
the later addition of deletion gave uploaders the loophole through which
they could not confuse downloaders of their packages.
On 29 September 2014 07:36, M.-A. Lemburg m...@egenix.com wrote:
On 28.09.2014 21:31, Donald
On 9/28/14 5:23 PM, Donald Stufft wrote:
You can delete them and then reupload the same file with different
contents.
Sorry, but I am confused: what does different content mean in contrast
to same file?
___
Distutils-SIG maillist -
M.-A. Lemburg mal at egenix.com writes:
-1.
It does happen that files need to be reuploaded because of a bug
in the release process and how people manage their code is really
*their* business, not that of PyPI.
It's not just the business of the package authors, because as soon as it's
And here's a version run through a for other people to read filter ;)
From the beginning uploaded files were immutable, but the later we added
the ability to delete releases which gave uploaders the loophole through
which they could confuse downloaders of their packages.
On 29 September 2014
On 29 September 2014 10:36, M.-A. Lemburg m...@egenix.com wrote:
-1.
It does happen that files need to be reuploaded because of a bug
in the release process and how people manage their code is really
*their* business, not that of PyPI.
FWIW, I am getting increasingly annoyed how PyPI and
He means a file with the same file name, but not necessarily the same
content.
On 29 September 2014 07:54, John Yeuk Hon Wong gokoproj...@gmail.com
wrote:
On 9/28/14 5:23 PM, Donald Stufft wrote:
You can delete them and then reupload the same file with different
contents.
Sorry, but I
On 09/28/2014 02:54 PM, John Yeuk Hon Wong wrote:
On 9/28/14 5:23 PM, Donald Stufft wrote:
You can delete them and then reupload the same file with different contents.
Sorry, but I am confused: what does different content mean in contrast to same
file?
Same file name, but different stuff
On Sep 28, 2014, at 5:36 PM, M.-A. Lemburg
m...@egenix.commailto:m...@egenix.com wrote:
On 28.09.2014 21:31, Donald Stufft wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload
On Sep 28, 2014, at 5:36 PM, M.-A. Lemburg
m...@egenix.commailto:m...@egenix.com wrote:
On 28.09.2014 21:31, Donald Stufft wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload
On 09/28/2014 02:36 PM, M.-A. Lemburg wrote:
-1.
It does happen that files need to be reuploaded because of a bug
in the release process and how people manage their code is really
*their* business, not that of PyPI.
There exists problems in the ecosphere now with pylockfile because two
On 29 September 2014 08:02, Donald Stufft donald.stu...@rackspace.com
wrote:
I forgot to mention, there is also testpypi.python.org which can be used
to test
builds prior to publishing them to PyPI. There is also devpi which I
believe has
the option to push from one of the devpi indexes
+1 I know I abused this a couple times a couple years ago, but it
bothered me that I could. It also worried me because if my account
were ever compromised, someone could release malware under files named
exactly the same as my real released software. This won't prevent them
from deleting those
Thanks for the well-reasoned response Nick.
Donald: +1 to your proposal. This will increase stability for the main
package repository, which is a good direction to move toward.
On Sun, Sep 28, 2014 at 3:51 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 Sep 2014 07:37, M.-A. Lemburg
On Sun, Sep 28, 2014 at 02:21:11PM -0700, Chris Jerdonek wrote:
Would this also affect the ability to update the readme information
for a version on PyPI (i.e. the information displayed on the default
home page generated by PyPI for the release) once the version has
already been uploaded to
On Sep 28, 2014, at 12:31 PM, Donald Stufft donald.stu...@rackspace.com wrote:
Hello All!
I'd like to discuss the idea of moving PyPI to having immutable files. This
would mean that once you publish a particular file you can never reupload that
file again with different contents. This
71 matches
Mail list logo
