2.4.1.post1 version in source

[dateutil]

2.4.1.post1 version in source

[pganssle]

@papachoco Can you clarify what you mean by that? Something I can reproduce? I ran pip install python-dateutil --no-use-wheel in a virtualenv and it installed python-dateutil.2.4.1.post1.tar.gz with no problems.

I've also tried pip install dateutil --no-use-wheel --no-cache --egg, it downloads the post1.tar.gz just fine and installs it as normal.

Edit: Actually, I see what you mean, I didn't realize that "buildout" is another tool, and I guess it's more sensitive to the version string in setup.py? I'm hesitant to experiment too much with this, so I'll try playing with it on a test project until I get something that works for pip and buildout.

Alternatively, there's a new timezone database out, so maybe I'll just do a bit of rebasing and generate a small 2.4.2 release. I'm not sure if people are bothered by a quick release schedule like that - I think 2.4.1 is less than a month old at this point.

[papachoco]

Thanks for the reply. It's simply a matter to change the version of init.py to 2.4.1.post1

[graingert]

having a different version in the source and on PyPI breaks a lot of different things!

now if you do "pip install -U" pip will always attempt to install 2.4.1.post1

[pganssle]

@graingert Is that a bug? 2.4.1.post1 and 2.4.1 are identical, except 2.4.1.post1 has the test suite included in the source distribution. This does not seem to me to be a problem.

@papachoco I have gotten zc.buildout, but it seems a bit more complicated than pip. Can you provide me some kind of MWE config file or something that can replicate the problem? I can keep uploading .postN versions all day, but I want to make sure that what I'm doing will actually work before I add yet another (dubious) "version" to dateutil. I'll continue fiddling with buildout, but it'll be much faster if I don't have to figure out how to get the problem to occur myself.

[papachoco]

Paul,

I am attaching a sample of a buildout configuration that replicates the
issue

Thanks

Carlos

On Mon, Mar 30, 2015 at 8:01 PM, Paul G. [email protected] wrote:

@graingert https://github.com/graingert Is that a bug? 2.4.1.post1 and
2.4.1 are identical, except 2.4.1.post1 has the test suite included in the
source distribution. This does not seem to me to be a problem.

@papachoco https://github.com/papachoco I have gotten zc.buildout, but
it seems a bit more complicated than pip. Can you provide me some kind of
MWE config file or something that can replicate the problem? I can keep
uploading .postN versions all day, but I want to make sure that what I'm
doing will actually work before I add yet another (dubious) "version" to
dateutil. I'll continue fiddling with buildout, but it'll be much faster if
I don't have to figure out how to get the problem to occur myself.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[pganssle]

@papachoco The attachment didn't come through. You can send directly to my e-mail at [E-mail received - redacted] if you wish.

At this point, I'm thinking maybe the best thing to do is to remove the .post1 files and just leave the python-dateutil-2.4.1.tar.bz2 file up there (which is the same as the .post1 version. I'll also prepare a 2.4.2 bugfix / timezone update release in the next week or so, which will be released properly as a .tar.gz. Would that break anyone's workflow?

[graingert]

The issue is not about the "post1" in general.

The only requirement so as to not break pip 6.0.8 is that the version in "setup.py" must match the version in PyPI.

However you set "2.4.1" in setup.py and "2.4.1.post1" in PyPI.

[graingert]

At this point, I'm thinking maybe the best thing to do is to remove the .post1 files and just leave the python-dateutil-2.4.1.tar.bz2 file up there (which is the same as the .post1 version. I'll also prepare a 2.4.2 bugfix / timezone update release in the next week or so, which will be released properly as a .tar.gz. Would that break anyone's workflow?

Removing 2.4.1.post1 will break anyone trying to install this specific version, you should just re-release 2.4.1.post1 as 2.4.2 (remember to update the version everywhere or you'll make another broken package).

[papachoco]

+1

On Tue, Mar 31, 2015 at 7:30 AM, Thomas Grainger [email protected]
wrote:

At this point, I'm thinking maybe the best thing to do is to remove the
.post1 files and just leave the python-dateutil-2.4.1.tar.bz2 file up there
(which is the same as the .post1 version. I'll also prepare a 2.4.2 bugfix
/ timezone update release in the next week or so, which will be released
properly as a .tar.gz. Would that break anyone's workflow?

Removing 2.4.1.post1 will break anyone trying to install this specific
version, you should just re-release 2.4.1.post1 as 2.4.2.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[pganssle]

@graingert Who would try to install the .post1 version? It's identical to the 2.4.1 version - the only reason there's a post1 version at all is because I didn't realize that you can't delete and re-release source distributions with the same numeric version (the code is identical, but the original source distributions didn't include the test suite because of a bug in I think setuptools).

The only reason I didn't change the version string in the code was because I was under the impression that the postN notation was for problems with the build, and that the true "version number" for 2.4.1 and 2.4.1.post1 would be the same.

Since the .post1 distributions are evidently broken anyway, I think it's reasonable to remove them, then move on to 2.4.2 quickly so that if there's any problem with using a .tar.bz2, it will be brief.

[graingert]

@pganssle I did, because I was notified by my build process that python-dateutil had updated, so I bumped the version.

[pganssle]

Hm. OK. Then I'll leave as is and prepare a 2.4.2 release. I'll need to do a bit of refactoring on the repo, though. Sorry to leave people in a lurch like this.

[pganssle]

OK, I've generated a 2.4.2 release. Hopefully this hasn't further broken anyone's system and has resolved the ongoing issues.

Sorry about these problems, guys, thanks for the feedback.