PEP-440 .devN releases should not be considered pre-releases

[ashleysommer]

I am developer and maintainer of the sanic-cors and sanic-plugins-framwork python libraries.
I use the PEP-440 guidelines for versioning in sanic-plugins-framework.
sanic-plugins-framework release versions look like this: 0.6.4.dev20181101

I've had a couple of issues raised this year about incomptibilities with pipenv and the PEP-440 versioning used in sanic-plugins-framework. I know pepenv prefers semver versions over PEP-440, but I wanted to open this discussion in order to try to come to a resolution for the users of those libraries.

Related:
ashleysommer/sanic-plugin-toolkit#4
ashleysommer/sanic-plugin-toolkit#9
#2002
#2063

It appears earlier related issues resolving versions with .devN suffix are now fixed, but users are still required to use the --pre flag in order to install them.

I believe this is incorrect behaviour, because my interpretation of the PEP-440 document is that the .devN suffix does not imply a pre-release version.

Reading this section of PEP-440 in Developmental Releases:
https://www.python.org/dev/peps/pep-0440/#id27
It shows that .devN can be applied on pre-release, release-candidate, release, and post-release versions. Therefore to me a developmental release is not the same as a pre-release.
In fact, see this section in PEP-440 regarding compatibility with other forms of semantic-versioning:
https://www.python.org/dev/peps/pep-0440/#id48
Specifically:

One possible mechanism to translate such semantic versioning based source labels to compatible public versions is to use the .devN suffix

So to me that implies that using .devN will increase compatibility of publicly released versions, with semantic versioing systems, not decrease it.

Currently using --pre to install these releases is not a good solution for the users.

There is a workaround to specify pipenv install sanic-cors --pre to resolve pre-release dependency, BUT this flag affects all other dependencies (for example it will coverage==5.0.3a, etc).

[techalchemy]

We are very familiar with the pep, however, as you assuredly know from your research, we use pip to install things, and pip also treats dev releases as prereleases.

For example:

$ pip install --pre sanic-plugins-framework
...
Successfully installed aiofiles-0.4.0 httptools-0.0.11 multidict-4.4.2 sanic-0.8.3 sanic-plugins-framework-0.6.4.dev20181101 ujson-1.35 uvloop-0.12.0rc1 websockets-5.0.1
...
$ pip list | grep -i plugins-framework
Sanic-Plugins-Framework 0.6.4.dev20181101

So would you mind linking the issue you've filed against pip?

[techalchemy]

I know pepenv prefers semver versions over PEP-440, but I wanted to open this discussion in order to try to come to a resolution for the users of those libraries.

I also just want to take the opportunity to say I have actually no idea what you're referring to on this point because we have no position on semver... we have an implementation with limitations in it, and if you have a bug to report about that we'd be happy to hear about it but we certainly don't have any strong feelings about how people version things. Pipenv itself doesn't even implement a sort order that is different from pip's when evaluating versions, it uses native packaging.version.Version objects to do comparisons with which don't even allow the kind of deviations you're describing.

Any behaviors here are not malicious acts by pipenv or attacks by its maintainers on the semantic versioning scheme OR on pep 440, please don't come to the issue tracker acting like we are personally crusading against semver. This is the first time anyone has ever even suggested (to me at least) that we even have a position on the topic. If you take the time to look, we even have an issue open on the topic (#1760) with our plan for the path forward -- if you want to implement that, well, probably you should write an enhancement proposal so we can nail down the behavior, but we'd certainly appreciate the contribution.

As far as the pep itself, we aren't likely to break from pip's behavior as a reference whether or not you agree with it, since it's the behavior users expect. Thanks for filing the issue, sorry we can't be of more help.

[ashleysommer]

@techalchemy
It seems you've taken offence to my opening this issue.
That was certainly not my intent, and I am sorry if my language has been interpreted as attacking the pipenv library in some way. I was not. I was wanting to open a discussion on this matter so that I can come to a resolution for the users of my libraries.

$ pip install --pre sanic-plugins-framework
...
Successfully installed aiofiles-0.4.0 httptools-0.0.11 multidict-4.4.2 sanic-0.8.3 sanic-plugins-framework->0.6.4.dev20181101 ujson-1.35 uvloop-0.12.0rc1 websockets-5.0.1
...
$ pip list | grep -i plugins-framework
Sanic-Plugins-Framework 0.6.4.dev20181101

But pip by itself can install sanic-plugins-framework without using --pre.

$ pip3 install sanic-plugins-framework
...
Successfully installed aiofiles-0.4.0 httptools-0.0.11 multidict-4.4.2 sanic-0.8.3 sanic-plugins-framework-0.6.4.dev20181101 ujson-1.35 uvloop-0.12.0rc1 websockets-5.0.1
...

$ pip list | grep -i plugins-framework
Sanic-Plugins-Framework 0.6.4.dev20181101

The reason I opened this issue against the pipenv repository is because installing the library works fine using pip without --pre (in fact that is the way users normally install this library) but the behaviour of pipenv is not the same, using pipenv you need to add --pre.

I also just want to take the opportunity to say I have actually no idea what you're referring to on this point because we have no position on semver.

That is my mistake. I personally don't use pipenv myself, but a colleague who does use it, told me that pipenv prefers semver-compliant versions over PEP-440. A couple of the PEP440-related pipenv issues that I read about this morning seemed to me to also give that impression. But I see now that I'm wrong, and I've modified my original post to reflect that.

Any behaviors here are not malicious acts by pipenv or attacks by its maintainers on the semantic versioning scheme OR on pep 440

I did not say there was any malicious acts, nor did I think there was. At no point did I think pipenv or its maintainers were attacking anything, and I don't know why you thought that.

[techalchemy]

So is the actual problem that pipenv cant install sanic plugins framework? That’s because we don’t select prerelease candidates by default when they are the only choice that satisfies a dependency. We would like to do that but it’s pretty complicated due to some implementation details involving hooking into pip internals. I haven’t looked at this recently but it was a roadblock as of a few months ago

[ashleysommer]

So is the actual problem that pipenv cant install sanic plugins framework?

Yes, that is what this Issue is about. Sorry if that wasn't clear in the original post.

The crux of the matter is that users can't install spf using pipenv unless --pre is added. But SanicPluginsFramework releases are not pre-release versions.

If it is the pip library that is causing that, by incorrectly interpreting .devN suffix as implying pre-release, then I will open an issue against the pip project repo.

What I am seeing is that pip install sanic-plugins-framework will work fine and install the latest version (0.6.4.dev20181101), but pipenv install sanic-plugins-framework does not work. Users can add --pre to make the pipenv command work, but doing so they get pre-release versions of other things like coverage==5.0.3a, etc.

I've worked around this for now by releasing a "0.6.5" version of SanicPluginsFramework, without the .devN extension.

[techalchemy]

The main behavioral difference here between pip and pipenv is actually that pip makes an assumption that it should install an ‘unreleased’ version (the fact that it’s a dev or rc or an alpha isn’t that important, the sort priority favors everything above dev options when possible). Pip assumes this if and only if there is no released version available in the index (this is technically correct according to the PEP).

Pipenv doesn’t do this, not for any philosophical reason, but just because we haven’t implemented the fallback properly. You can file an issue to pip if you like but I suspect they will tell you that a dev release is a pre release and if you put it on a postrelease it is a prerelease of a postrelease. Internally they use --pre as a way of lifting all restrictions on what they are allowing to be included in the candidate set — postreleases are already allowed by default which is why the flag makes sense (and the behavior probably does too, to a certain extent)