On 14 August 2013 15:07, Marcus Smith 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 inclus
> *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
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 ad
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
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
