Hi, I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error: Error processing form This filename has previously been used, you should use a different version. Any chance of a post3 upload so I can upload some matching wheels? Sorry about that, Matthew
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there. Chuck
On Thu, Oct 8, 2015 at 8:39 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there.
If you manage a release without a `post` post-fix, then I would not have to worry right away about what to do about a statsmodels setup.py that cannot handle it. Josef
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Oct 8, 2015 at 7:19 PM, <josef.pktd@gmail.com> wrote:
On Thu, Oct 8, 2015 at 8:39 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there.
If you manage a release without a `post` post-fix, then I would not have to worry right away about what to do about a statsmodels setup.py that cannot handle it.
It's a learning experience all round :-) Might take a look at NumpyVersion in numpy/lib if handling versioning is a problem. But... NumpyVersion is buggy also In [7]: NumpyVersion('1.10.0.post1') < '1.10.0' Out[7]: True <snip> Chuck <https://mail.scipy.org/mailman/listinfo/numpy-discussion>
On Oct 8, 2015 5:39 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com>
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different
version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the
wrote: troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there. I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads. If this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we probably won't run out of numbers :-). -n
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 8, 2015 5:39 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com>
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different
version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the
wrote: troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there.
I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads. If this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that? Chuck
Hi, On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 8, 2015 5:39 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there.
I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads. If this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that?
Is the summary this: * never have an actual numpy version .postN; * releases always have source with a clean Major.Minor.Micro release number; * binary packages for Minor.Minor.Micro release numbers may have filenames ending in .postN * these binary packages should be uploaded via the web interface to avoid creating a new release ? Matthew
On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 8, 2015 5:39 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <
wrote:
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2 - containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from
matthew.brett@gmail.com> there.
I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads. If this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 --
we
probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that?
Is the summary this:
* never have an actual numpy version .postN; * releases always have source with a clean Major.Minor.Micro release number; * binary packages for Minor.Minor.Micro release numbers may have filenames ending in .postN
The few times in the past when we've needed to fix a binary, we've just re-uploaded it with the same name. This seems much preferable to me than confusing users with a post-fix on PyPi that doesn't even match ``numpy.__version__`` and that is so uncommon that I've never seen it used anywhere. If re-uploading with the same name is now disallowed by PyPi (is it?) then bumping the micro version number as Nathaniel proposes would be the way to go imho. Ralf
* these binary packages should be uploaded via the web interface to avoid creating a new release
?
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 8, 2015 5:39 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <
wrote:
Hi,
I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. Using twine to do the upload generated a new release - 1.10.0.post2
containing only the wheels. I deleted that new release to avoid confusion, but now, when I try and upload the wheels to the 1.10.0 pypi release via the web form, I get this error:
Error processing form
This filename has previously been used, you should use a different version.
Any chance of a post3 upload so I can upload some matching wheels?
Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from
matthew.brett@gmail.com> - there.
I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads.
If
this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that?
Is the summary this:
* never have an actual numpy version .postN; * releases always have source with a clean Major.Minor.Micro release number; * binary packages for Minor.Minor.Micro release numbers may have filenames ending in .postN
The few times in the past when we've needed to fix a binary, we've just re-uploaded it with the same name. This seems much preferable to me than confusing users with a post-fix on PyPi that doesn't even match ``numpy.__version__`` and that is so uncommon that I've never seen it used anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?) then bumping the micro version number as Nathaniel proposes would be the way to go imho.
You are not allowed to reuse a file name, and numpy.__version__ must match the file name or pip install will fail. This has all been a bit of experimentation and I think we have learned something. Agree about not using the `.postN` suffix. I expect we will have fewer problems next time around. Chuck
On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 8, 2015 5:39 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <matthew.brett@gmail.com> wrote: > > Hi, > > I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. > Using twine to do the upload generated a new release - 1.10.0.post2 > - > containing only the wheels. I deleted that new release to avoid > confusion, but now, when I try and upload the wheels to the 1.10.0 > pypi release via the web form, I get this error: > > Error processing form > > This filename has previously been used, you should use a different > version. > > Any chance of a post3 upload so I can upload some matching wheels? > > Sorry about that,
Yeah, pipy is why we are on post2 already. Given the problem with msvc9, I think we are due for 1.10.1 in a day or two. Or, I could revert the troublesome commit and do a post3 tomorrow. Hmm... decisions, decisions. I'll see if Julian has anything to say in the morning and go from there.
I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads. If this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that?
Is the summary this:
* never have an actual numpy version .postN; * releases always have source with a clean Major.Minor.Micro release number; * binary packages for Minor.Minor.Micro release numbers may have filenames ending in .postN
The few times in the past when we've needed to fix a binary, we've just re-uploaded it with the same name. This seems much preferable to me than confusing users with a post-fix on PyPi that doesn't even match ``numpy.__version__`` and that is so uncommon that I've never seen it used anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?) then bumping the micro version number as Nathaniel proposes would be the way to go imho.
You are not allowed to reuse a file name, and numpy.__version__ must match the file name or pip install will fail. This has all been a bit of experimentation and I think we have learned something. Agree about not using the `.postN` suffix. I expect we will have fewer problems next time around.
OK - any chance of a 1.10.1 release urgently? Otherwise the wheel installs don't work on OSX... Matthew
On Fri, Oct 9, 2015 at 12:17 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers <ralf.gommers@gmail.com>
On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com>
wrote:
On Oct 8, 2015 5:39 PM, "Charles R Harris" <
charlesr.harris@gmail.com>
wrote: > > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett > <matthew.brett@gmail.com> > wrote: >> >> Hi, >> >> I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. >> Using twine to do the upload generated a new release - 1.10.0.post2 >> - >> containing only the wheels. I deleted that new release to avoid >> confusion, but now, when I try and upload the wheels to the 1.10.0 >> pypi release via the web form, I get this error: >> >> Error processing form >> >> This filename has previously been used, you should use a different >> version. >> >> Any chance of a post3 upload so I can upload some matching wheels? >> >> Sorry about that, > > > Yeah, pipy is why we are on post2 already. Given the problem with > msvc9, > I think we are due for 1.10.1 in a day or two. Or, I could revert > the > troublesome commit and do a post3 tomorrow. Hmm... decisions, > decisions. > I'll see if Julian has anything to say in the morning and go from > there.
I vote that we increment the micro number every time we upload a new source release, and reserve the postN suffix for binary-only uploads. If this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 -- we probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that?
Is the summary this:
* never have an actual numpy version .postN; * releases always have source with a clean Major.Minor.Micro release number; * binary packages for Minor.Minor.Micro release numbers may have filenames ending in .postN
The few times in the past when we've needed to fix a binary, we've just re-uploaded it with the same name. This seems much preferable to me than confusing users with a post-fix on PyPi that doesn't even match ``numpy.__version__`` and that is so uncommon that I've never seen it used anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?)
wrote: then
bumping the micro version number as Nathaniel proposes would be the way to go imho.
You are not allowed to reuse a file name, and numpy.__version__ must match the file name or pip install will fail. This has all been a bit of experimentation and I think we have learned something. Agree about not using the `.postN` suffix. I expect we will have fewer problems next time around.
OK - any chance of a 1.10.1 release urgently? Otherwise the wheel installs don't work on OSX...
Working on it. There is a problem with msvc9 that needs to be addressed, otherwise it would be out already. Chuck
On Fri, Oct 9, 2015 at 11:54 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Fri, Oct 9, 2015 at 12:17 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith <njs@pobox.com> wrote: > > On Oct 8, 2015 5:39 PM, "Charles R Harris" > <charlesr.harris@gmail.com> > wrote: > > > > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett > > <matthew.brett@gmail.com> > > wrote: > >> > >> Hi, > >> > >> I'm afraid I made a mistake uploading OSX wheels for numpy > >> 1.10.0. > >> Using twine to do the upload generated a new release - > >> 1.10.0.post2 > >> - > >> containing only the wheels. I deleted that new release to avoid > >> confusion, but now, when I try and upload the wheels to the > >> 1.10.0 > >> pypi release via the web form, I get this error: > >> > >> Error processing form > >> > >> This filename has previously been used, you should use a > >> different > >> version. > >> > >> Any chance of a post3 upload so I can upload some matching > >> wheels? > >> > >> Sorry about that, > > > > > > Yeah, pipy is why we are on post2 already. Given the problem with > > msvc9, > > I think we are due for 1.10.1 in a day or two. Or, I could revert > > the > > troublesome commit and do a post3 tomorrow. Hmm... decisions, > > decisions. > > I'll see if Julian has anything to say in the morning and go from > > there. > > I vote that we increment the micro number every time we upload a > new > source release, and reserve the postN suffix for binary-only > uploads. > If > this means we have a tiny 1.10.1 then oh well, there's always > 1.10.2 > -- we > probably won't run out of numbers :-).
The only difference between 1.10.0 and 1.10.0.post2 is that the latter is signed. Sigh. We need to capture this experience in the HOWTO_RELEASE document. Matthew, can you take care of that?
Is the summary this:
* never have an actual numpy version .postN; * releases always have source with a clean Major.Minor.Micro release number; * binary packages for Minor.Minor.Micro release numbers may have filenames ending in .postN
The few times in the past when we've needed to fix a binary, we've just re-uploaded it with the same name. This seems much preferable to me than confusing users with a post-fix on PyPi that doesn't even match ``numpy.__version__`` and that is so uncommon that I've never seen it used anywhere.
If re-uploading with the same name is now disallowed by PyPi (is it?) then bumping the micro version number as Nathaniel proposes would be the way to go imho.
You are not allowed to reuse a file name, and numpy.__version__ must match the file name or pip install will fail. This has all been a bit of experimentation and I think we have learned something. Agree about not using the `.postN` suffix. I expect we will have fewer problems next time around.
OK - any chance of a 1.10.1 release urgently? Otherwise the wheel installs don't work on OSX...
Working on it. There is a problem with msvc9 that needs to be addressed, otherwise it would be out already.
Great, thanks - meanwhile I'll get onto the HOWTO_RELEASE PR in the next couple of hours. Matthew
participants (5)
-
Charles R Harris -
josef.pktd＠gmail.com -
Matthew Brett -
Nathaniel Smith -
Ralf Gommers