Re: [Distutils] ensurepip in linux distros

[Nick Coghlan]

On 7 September 2015 at 01:37, Marcus Smith  wrote:
>>
>> then bundles the system
>> version back up with rewheel for installation into Python virtual
>> environments.
>
>
> this "bundles the system version back up" step happens when?

When ensurepip.bootstrap() runs - Fedora's system Python is patched to
do that rather than install from the embedded wheel files (technically
it falls back to the latter code path, but we omit those from the
Fedora system Python package and include a runtime dependency on
python-pip and python-setuptools instead).

> which fedora version did this start?

I think it was F21 (Dec 2014), may have been F22 (May 2015).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Ben Finney]

Nick Coghlan  writes:

> On 7 September 2015 at 02:09, Marcus Smith  wrote:
> > For example, down the road when there's Wheel 2.0, what's the "Current
> > Specs" for wheel?
>
> Yes, but I think that's easy enough to handle by having a default URL
> that always goes to the latest version of the spec, and moving
> previous versions to URLs that include the version number.


Or consistently publish each spec version to a predictable URL with the
version number, and have the default URL *redirect* to whatever is the
current-versioned spec.


That way, the URL works as people expect, *and* the resulting
destination gives a URL that (when inevitably copy-and-pasted) will
retain its meaning over time.

-- 
 \   Moriarty: “Forty thousand million billion dollars? That money |
  `\must be worth a fortune!” —The Goon Show, _The Sale of |
_o__)   Manhattan_ |
Ben Finney

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Marcus Smith]

> That way, the URL works as people expect, *and* the resulting
> > destination gives a URL that (when inevitably copy-and-pasted) will
> > retain its meaning over time.
>
> Yes, ReadTheDocs does let us do that.


well, it lets you do it for a whole project.
we'd have to have a project per spec for it to work like that.
we've been talking about all specs being in one project (PyPUG)

I think it we'd either have to:
1) only render the latest version, and construct an index of links to the
unrendered old versions in vcs history
or
2) use a custom tailored tool to publish/render this like we want.
or
3) use distinct documents for distinct versions as peers in the src tree.


-Marcus
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Nick Coghlan]

On 7 September 2015 at 14:11, Marcus Smith  wrote:
>
>
>> > That way, the URL works as people expect, *and* the resulting
>> > destination gives a URL that (when inevitably copy-and-pasted) will
>> > retain its meaning over time.
>>
>> Yes, ReadTheDocs does let us do that.
>
>
> well, it lets you do it for a whole project.

RTD also has page redirects now:
https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects
(I thought the same thing you did, but found that when double
checking)

So we *could* redirect unqualified links to qualified ones if we
wanted to. I just don't want to :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Nick Coghlan]

On 7 September 2015 at 02:09, Marcus Smith  wrote:
> 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?

Yes, but I think that's easy enough to handle by having a default URL
that always goes to the latest version of the spec, and moving
previous versions to URLs that include the version number.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Nick Coghlan]

On 7 September 2015 at 09:42, Ben Finney  wrote:
> Nick Coghlan  writes:
>
>> On 7 September 2015 at 02:09, Marcus Smith  wrote:
>> > For example, down the road when there's Wheel 2.0, what's the "Current
>> > Specs" for wheel?
>>
>> Yes, but I think that's easy enough to handle by having a default URL
>> that always goes to the latest version of the spec, and moving
>> previous versions to URLs that include the version number.
>
> 
> Or consistently publish each spec version to a predictable URL with the
> version number, and have the default URL *redirect* to whatever is the
> current-versioned spec.
> 
>
> That way, the URL works as people expect, *and* the resulting
> destination gives a URL that (when inevitably copy-and-pasted) will
> retain its meaning over time.

Yes, ReadTheDocs does let us do that. However, there's actually a
problem with it, and it's this: it perpetuates the myth that it is
possible to publish viable packaging software without committing to
ongoing maintenance of that software to track changes to distribution
formats and user experience expectations.

Software distribution *fundamentally* involves interacting with the
outside world, and coping with evolving interoperability expectations.
Users should be able to grab the latest version of a packaging tool
and be confident that it supports the latest interoperability
standards (modulo a rollout window of a few weeks or maybe a few
months for tools designed for relatively slow moving environments).

This is the problem we always hit with distutils, and the one we still
regularly hit with the Linux distributions: their update and rollout
cycles are too slow, so they can't keep up with user expectations.

Thus, the mindset we want to cultivate amongst tool developers is "I
commit to ensuring my project gains support for the latest versions of
the Python packaging interoperability standards in a timely manner, as
well as supporting legacy versions of those standards for backwards
compatibility purposes", rather than "My project supports version 1.0
of the interoperability standards, and I might upgrade to 2.0 when
that happens. If I feel like it, and I have time. Maybe".

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] BDFL Delegates for distutils-sig PEPs

[Nick Coghlan]

On 7 September 2015 at 01:43, Marcus Smith  wrote:
> ok, so this is PEP 474
> where's the activity for the forge idea happening?   python-dev list?

While the final discussions will need to move to python-dev, the
preliminary discussions are taking place on the core-workflow mailing
list: https://mail.python.org/mailman/listinfo/core-workflow

My Kallithea based proposal is at https://www.python.org/dev/peps/pep-0474/
Donald's GitHub+Phabricator proposal is at
https://www.python.org/dev/peps/pep-0481/

Brett has asked that the prototypes focus on the main CPython repo,
even though we'd be moving the support repos first in any actual
rollout: https://mail.python.org/pipermail/core-workflow/2015-August/000189.html

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] BDFL Delegates for distutils-sig PEPs

[Marcus Smith]

ok, so this is PEP 474
where's the activity for the forge idea happening?   python-dev list?

On Sat, Sep 5, 2015 at 10:47 PM, Nick Coghlan  wrote:

>
> On 6 Sep 2015 10:39, "Marcus Smith"  wrote:
> >
> > yea, I like the idea of our own authoritative Pypa project for
> proposals, and maybe have it hold the final "Specs" we're talking about as
> well (and just have PyPUG link to them or whatever).
> >
> > I *think* it would lower the bar for people considering getting involved
> with writing specs and enhancements.
>
> Brett Cannon set an October 31st deadline for the forge.python.org
> proofs-of-concept, so that aspect will be changing regardless (either to a
> PR-capable Kallithea, or GitHub+Phabricator)
>
> Cheers,
> Nick.
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] ensurepip in linux distros

[Marcus Smith]

>
>
> then bundles the system
> version back up with rewheel for installation into Python virtual
> environments.


this "bundles the system version back up" step happens when?
which fedora version did this start?
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Marcus Smith]

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?

--Marcus

On Sat, Sep 5, 2015 at 1:35 AM, Nick Coghlan  wrote:

> On 5 September 2015 at 16:46, Nathaniel Smith  wrote:
> > On Fri, Sep 4, 2015 at 9:24 PM, Marcus Smith  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   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig