One thought that comes to mind is how to present specs that deal with
formats and artifacts that persist for years.
For example, down the road when there's Wheel 2.0, what's the "Current
Specs" for wheel?
I would describe 2.0 is the "Latest" spec, but "Current Specs" includes all
versions we're attempting to support, so we'd want the "Current Specs" page
to easily show all the versions, and not have to dig them out from version
control or something, right?
On Sat, Sep 5, 2015 at 1:35 AM, Nick Coghlan <ncog...@gmail.com> wrote:
> On 5 September 2015 at 16:46, Nathaniel Smith <n...@pobox.com> wrote:> > On Fri, Sep 4, 2015 at 9:24 PM, Marcus Smith <qwc...@gmail.com> wrote:> >>> I don't have a specific problem with the specs living somewhere else> >>> as well, I just don't think moving a lengthy document full of edge> cases> >>> from one location to another is going to make things better> >>> >> If I may, I don't think that really captures Nick's idea.> >>> >> I think it's about clearly distinguishing the following:> >>> >> 1) Current Specs (for metadata, versioning, pypi etc..)> >> 2) Proposals to adjust or add to the Current Specs> >>> >> We don't have a clear distinction right now. We just have a series of> >> PEPs, and it's work to figure out where the actual current spec is at,> in> >> the noise of rationales and transition plans etc...> >> > Speaking as someone who has been pretty confused in the past trying to> > look up what the actual current rules are for something like version> > numbers or metadata (is this the current PEP? oh wait this one's newer> > -- oh but wait is the newer one still in development? or maybe> > abandoned?, etc.): +1>> We also have specs like Tarek's database of installed distributions> (https://www.python.org/dev/peps/pep-0376/), where we kept the> "dist-info" parts, but not any of the API proposals.>> *Existing* formats (like sdist) could also be specified there without> requiring a new PEP (modulo people's time to do the work, but at least> having a place for such specs to *go* would be a good first step).>> Cheers,> Nick.>> --> Nick Coghlan | ncog...@gmail.com | Brisbane, Australia>
Distutils-SIG maillist - Dist...@python.org