PEP440 and fork versioning

I'm wondering if PEP440 should recommend how to version forks? It's fairly common to fork dependencies temporarily until the change can be released upstream. Ideally, you want to version a fork (and keep the same name) so that it fulfills the requirement, but be obvious that it's a fork. Although pip allows overriding requirement consistency, consistency is preferred, and needed in cases where a `pkg_resources.require` enforces it in a console script. As it is now, the "post-release" scheme works for this, but it's not the intended use case. Marcus

I'm noticing the mention of forks in PEP426 for "provides". so theoretically, `pkg_resources.WorkingSet.resolve` would be updated at some point to account for "provides" in PEP426, and this feature would be surfaced as a setup keyword for users to use in their fork projects. On Wed, Aug 14, 2013 at 10:53 AM, Marcus Smith <qwcode@gmail.com> wrote:
I'm wondering if PEP440 should recommend how to version forks? It's fairly common to fork dependencies temporarily until the change can be released upstream.
Ideally, you want to version a fork (and keep the same name) so that it fulfills the requirement, but be obvious that it's a fork.
Although pip allows overriding requirement consistency, consistency is preferred, and needed in cases where a `pkg_resources.require` enforces it in a console script.
As it is now, the "post-release" scheme works for this, but it's not the intended use case.
Marcus

Distros actually need to do this fairly regularly for security patches and packaging tweaks, so it may be a good idea. I think local updates were one of the intended uses for post-releases, but that doesn't work if upstream is also using that suffix (and we know some projects do). *If* this was added to the PEP, I would add it as a new optional ".localN" suffix, with a recommendation that public index servers MUST disallow use of local numbering, since it is intended for downstream integrators to indicate the inclusion of additional changes relative to the upstream version. Outside a given integrators environment, the local numbering is no longer valid. Currently, the PEP assumes the use of an external numbering system to track that kind of local change (e.g. with RPM, one common tactic is to increase the release level rather than the version, so the version continues to match the upstream base). The rationale for adding it directly to the PEP would be to let people accurately track versions for local modifications, even if they're using virtualenv as their integration environment. "Provides" is a bit different, in that it covers more permanent forks and name changes, rather than the "fix things locally for immediate use, submit upstream patch as a good open source citizen" and "backport selected bug fixes from later versions" workflows that are pretty common in larger integration projects like Linux distros. Cheers, Nick.

*If* this was added to the PEP, I would add it as a new optional ".localN" suffix, with a recommendation that public index servers MUST disallow use of local numbering, since it is intended for downstream integrators to indicate the inclusion of additional changes relative to the upstream version. Outside a given integrators environment, the local numbering is no longer valid.
Seems like you have to add something like this, if you're not wanting "provides" to cover it. Like you mention, ".post" won't work in all cases. Otherwise people are left not changing the version, or changing the version in a way that could break consistency.

On 14 August 2013 15:07, Marcus Smith <qwcode@gmail.com> wrote:
*If* this was added to the PEP, I would add it as a new optional ".localN" suffix, with a recommendation that public index servers MUST disallow use of local numbering, since it is intended for downstream integrators to indicate the inclusion of additional changes relative to the upstream version. Outside a given integrators environment, the local numbering is no longer valid.
Seems like you have to add something like this, if you're not wanting "provides" to cover it. Like you mention, ".post" won't work in all cases. Otherwise people are left not changing the version, or changing the version in a way that could break consistency.
Yeah, I agree. To help keep track of this stuff (and to make pull requests a possibility), I created a "PyPI Metadata Formats" repo on BitBucket and filed this as the first issue: https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-local-numbering... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
Marcus Smith
-
Nick Coghlan