Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8113 > unrolled thread

Python Policy: Things to consider for Stretch

Back to article view | Back to linux.debian.maint.python

Contents

  Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-21 16:50 +0100
    Re: Python Policy: Things to consider for Stretch Barry Warsaw <barry@debian.org> - 2016-01-23 00:00 +0100
      Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-23 09:40 +0100
        Re: Python Policy: Things to consider for Stretch Barry Warsaw <barry@debian.org> - 2016-01-24 03:00 +0100
          Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-24 04:10 +0100
            Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-24 06:40 +0100
              Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-24 07:10 +0100
              Re: Python Policy: Things to consider for Stretch Barry Warsaw <barry@debian.org> - 2016-01-24 19:10 +0100
              Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-26 07:00 +0100
              Re: Python Policy: Things to consider for Stretch Dmitry Shachnev <mitya57@debian.org> - 2016-01-26 18:00 +0100
                Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-27 04:40 +0100
                  Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-27 05:20 +0100
                    Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-27 10:50 +0100
              Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-29 23:30 +0100
                Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-30 00:10 +0100
      Re: Python Policy: Things to consider for Stretch Paul Wise <pabs@debian.org> - 2016-02-16 01:10 +0100
        Re: Python Policy: Things to consider for Stretch Barry Warsaw <barry@debian.org> - 2016-02-16 01:50 +0100
          Re: Python Policy: Things to consider for Stretch Barry Warsaw <barry@debian.org> - 2016-02-16 02:00 +0100
          Re: Python Policy: Things to consider for Stretch Paul Wise <pabs@debian.org> - 2016-02-16 02:00 +0100
            Re: Python Policy: Things to consider for Stretch Barry Warsaw <barry@debian.org> - 2016-02-16 02:20 +0100
    Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-24 06:50 +0100
      Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-24 07:00 +0100
        Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-24 07:20 +0100
          Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-01-25 06:00 +0100
            Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-25 06:30 +0100
      Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-01-24 07:10 +0100
    Re: Python Policy: Things to consider for Stretch Scott Kitterman <debian@kitterman.com> - 2016-02-15 23:30 +0100
      Re: Python Policy: Things to consider for Stretch Ben Finney <ben+debian@benfinney.id.au> - 2016-02-16 03:50 +0100

Page 1 of 2  [1] 2  Next page →

#8113 — Python Policy: Things to consider for Stretch

[Multipart message — attachments visible in raw view] — view raw

I've taken a run through the current Python Policy to see where I think it 
needs to be updated for Stretch.  The updates largely fall into four 
categories:

1.  Update old examples
2.  Clean up old policy test that no longer applies
3.  Simplify things due to there only being one python version
4.  Make the text better match current practice

I've sent this twice now and the list didn't like it for different reasons, so 
I've posted [1] the diff I've come up with so far in rfcdiff format (because I 
think it's easier to read that unified diffs for this kind of thing).

This is just my opinion on stuff I found.  I'm interested in feedback on how 
these changes look and what else ought to be considered (no: rewrite the whole 
thing is not useful feedback unless you provide the text).

While I don't have any specific near-term deadlines for this, at least one of 
the proposals (killing off python:Provides) will take a little while to 
accomplish, so I would like to get consensus on what's reasonable sooner 
rather than later.

Scott K

[1] http://kitterman.com/debian/python-policy.new-from-old.diff.html

[toc] | [next] | [standalone]

#8130

[Multipart message — attachments visible in raw view] — view raw

On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:

>I've taken a run through the current Python Policy to see where I think it
>needs to be updated for Stretch.

Thanks Scott for the badly needed update.

Some comments, apologies for the lack of good quoting, or if I've read the
diff incorrectly.

2.5 Module Path

"Public Python modules must be installed in the system Python modules
directory, /usr/lib/python<X>.<Y>/dist-packages.  Public Python 3 modules must
be installed in /usr/lib/python3/dist-packages."

I think this could use a bit of disambiguation, sice "system Python modules"
could mean either Python generically, in which case the second sentence is in
conflict.  Do you mean "system Python 2 modules"?  If so, let's say that.
Also, since Python 2.7 is all there will be from now on, why not say that
explicitly?

A good reason not to would be because Policy needs to cover older releases
where there can be multiple versions of Python 2.  But then later in your diff
you seem to mention python2.7 as being associated with
/usr/local/lib/python2.<Y>/dist-packages.  So maybe say
/usr/local/lib/python2.7/dist-packages here too?  There really won't be any
other value for <Y> than 7.

3.4 Specifying Supported Versions

"The optional `X-Python-Version (preferred) or `XS-Python-Version` field..."

It's a little confusing because we're now saying we prefer not to have either
field.  How about "(previously preferred)" or just drop the parenthetical?

3.6 Provides

s/substituation/substitution/

B.2. dh_python2 and dh_python3

Again, I think here you want to say "Python2 and Python3" to disambiguate
between generic Python.

Other than that, +1

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8141

[Multipart message — attachments visible in raw view] — view raw

On Friday, January 22, 2016 05:55:19 PM Barry Warsaw wrote:
> On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:
> >I've taken a run through the current Python Policy to see where I think it
> >needs to be updated for Stretch.
> 
> Thanks Scott for the badly needed update.
> 
> Some comments, apologies for the lack of good quoting, or if I've read the
> diff incorrectly.
> 
> 2.5 Module Path
> 
> "Public Python modules must be installed in the system Python modules
> directory, /usr/lib/python<X>.<Y>/dist-packages.  Public Python 3 modules
> must be installed in /usr/lib/python3/dist-packages."
> 
> I think this could use a bit of disambiguation, sice "system Python modules"
> could mean either Python generically, in which case the second sentence is
> in conflict.  Do you mean "system Python 2 modules"?  If so, let's say
> that. Also, since Python 2.7 is all there will be from now on, why not say
> that explicitly?

Personally I seriously dislike the trend to call Python Python 2 (and I still 
thing approving a pep to invent /usr/bin/python2 because Arch went insane was 
a horrible idea).  There's an earlier spot in the document where it says that 
everything refers to python and python3 unless it's explicit.  I'll make this 
spot /usr/lib/python2.7/dist-packages and any risk of ambiguity is, I think, 
resolved.

> A good reason not to would be because Policy needs to cover older releases
> where there can be multiple versions of Python 2.  But then later in your
> diff you seem to mention python2.7 as being associated with
> /usr/local/lib/python2.<Y>/dist-packages.  So maybe say
> /usr/local/lib/python2.7/dist-packages here too?  There really won't be any
> other value for <Y> than 7.

We only need (I think) to cover packages being developed for the release the 
policy is for.  Squeeze was the last multi-python version release, so I think 
we're safe to remove python2.<Y> where way may not always be 7.

> 3.4 Specifying Supported Versions
> 
> "The optional `X-Python-Version (preferred) or `XS-Python-Version` field..."
> 
> It's a little confusing because we're now saying we prefer not to have
> either field.  How about "(previously preferred)" or just drop the
> parenthetical?

Makes sense.  I'll do that.

> 3.6 Provides
> 
> s/substituation/substitution/

Thanks.

> B.2. dh_python2 and dh_python3
> 
> Again, I think here you want to say "Python2 and Python3" to disambiguate
> between generic Python.

If I say Python and Python3, what version can the one that's not Python3 
possibly be?  I don't think it's any less confusing than starting to call what 
we've always called "Python" "Python 2".

> Other than that, +1

Thanks for reviewing.

Scott K

[toc] | [prev] | [next] | [standalone]

#8143

[Multipart message — attachments visible in raw view] — view raw

On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:

>Personally I seriously dislike the trend to call Python Python 2 (and I still
>thing approving a pep to invent /usr/bin/python2 because Arch went insane was
>a horrible idea).  There's an earlier spot in the document where it says that
>everything refers to python and python3 unless it's explicit.  I'll make this
>spot /usr/lib/python2.7/dist-packages and any risk of ambiguity is, I think,
>resolved.

I'll leave it to you, but my take on it is that "Python" is the generic term
for the language and its specification.  "Python 2" v "Python 3" provides
disambiguation when you're talking about specific major versions of the
language.  "Python 3.5" and such usually describe specific releases of the
CPython interpreter implementation (note how "CPython" is used to disambiguate
between alternative implementations of the language specification).  Finally,
python2.7, python3.4 and such are used to describe the executables that
provide the versions (e.g. mentally prepend them with /usr/bin).

All of this, except the last point perhaps, is orthogonal to the
/usr/bin/python2 issue you mention.

Back to the original point, to me saying "Python" and "Python 3" is confusing
or misleading, given the above definitions.  It's confusing because "Python 3"
*is* Python, so what's the difference?  It's misleading because it implies
that somehow "Python 3" isn't "Python".

>> B.2. dh_python2 and dh_python3
>> 
>> Again, I think here you want to say "Python2 and Python3" to disambiguate
>> between generic Python.  
>
>If I say Python and Python3, what version can the one that's not Python3
>possibly be?  I don't think it's any less confusing than starting to call
>what we've always called "Python" "Python 2".

See above, but to rephrase, "Python" is ambiguous in this context because you
could be talking about Python-the-language, not Python-some-release-version.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8144

[Multipart message — attachments visible in raw view] — view raw

On Saturday, January 23, 2016 08:50:49 PM Barry Warsaw wrote:
> On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:
> >Personally I seriously dislike the trend to call Python Python 2 (and I
> >still thing approving a pep to invent /usr/bin/python2 because Arch went
> >insane was a horrible idea).  There's an earlier spot in the document
> >where it says that everything refers to python and python3 unless it's
> >explicit.  I'll make this spot /usr/lib/python2.7/dist-packages and any
> >risk of ambiguity is, I think, resolved.
> 
> I'll leave it to you, but my take on it is that "Python" is the generic term
> for the language and its specification.  "Python 2" v "Python 3" provides
> disambiguation when you're talking about specific major versions of the
> language.  "Python 3.5" and such usually describe specific releases of the
> CPython interpreter implementation (note how "CPython" is used to
> disambiguate between alternative implementations of the language
> specification).  Finally, python2.7, python3.4 and such are used to
> describe the executables that provide the versions (e.g. mentally prepend
> them with /usr/bin).
> 
> All of this, except the last point perhaps, is orthogonal to the
> /usr/bin/python2 issue you mention.
> 
> Back to the original point, to me saying "Python" and "Python 3" is
> confusing or misleading, given the above definitions.  It's confusing
> because "Python 3" *is* Python, so what's the difference?  It's misleading
> because it implies that somehow "Python 3" isn't "Python".
> 
> >> B.2. dh_python2 and dh_python3
> >> 
> >> Again, I think here you want to say "Python2 and Python3" to disambiguate
> >> between generic Python.
> >
> >If I say Python and Python3, what version can the one that's not Python3
> >possibly be?  I don't think it's any less confusing than starting to call
> >what we've always called "Python" "Python 2".
> 
> See above, but to rephrase, "Python" is ambiguous in this context because
> you could be talking about Python-the-language, not
> Python-some-release-version.

I don't particularly agree, but if that's correct, then there's a large amount 
of change needed throughout the policy.  These certainly aren't the only 
places this comes up.  Ambiguous or not, I think the policy is mostly 
consistent in using python and python3 vice python2 and python3.  At this 
point I think internal consistency is probably more important, so if someone 
wants to go through and make all the python's that should be python2, etc then 
please send in a patch.

Scott K

[toc] | [prev] | [next] | [standalone]

#8145

Scott Kitterman <debian@kitterman.com> writes:

> I don't particularly agree, but if that's correct, then there's a
> large amount of change needed throughout the policy. These certainly
> aren't the only places this comes up.

Yes, that's likely because when the Debian Python policy was initially
drafted, there was no Python 3 anywhere close to entering Debian. So
“Python” and “Python 2” were less ambiguously conflated at that time.

Now that Python 2 and Python 3 are both commonly (and correctly)
referred to as “Python”, we need to take more care using the terms for
what we mean.

> Ambiguous or not, I think the policy is mostly consistent in using
> python and python3 vice python2 and python3.

Well that's another dimension of confusion :-) The term “python2” and
“python3” are named of commands, more than the names of languages.

I think you're right that this needs a general clean-up through the
policy document, to consistently use:

* “python2” to refer to that command only;

* “python3” to refer to that command only;

* “python” to refer to that command (and I'd suggest deprecating it
  where feasible);

* “Python 2” referring exclusively to that language version 2.x and no
  other versions of that language;

* “Python 3” referring exclusively to that language version 3.x and no
  other versions of that language;

* “Python” referring to the language implemented either as Python 2 or
  Python 3.

> At this point I think internal consistency is probably more important,
> so if someone wants to go through and make all the python's that
> should be python2, etc then please send in a patch.

I'll take that on. Send it to anywhere in particular? Or I can just send
it to this forum.

-- 
 \       “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\   so, but *where* do you stick the feather and call it macaroni?” |
_o__)                                           —_Pinky and The Brain_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8148

On Sunday, January 24, 2016 04:33:55 PM Ben Finney wrote:
> Scott Kitterman <debian@kitterman.com> writes:
> > I don't particularly agree, but if that's correct, then there's a
> > large amount of change needed throughout the policy. These certainly
> > aren't the only places this comes up.
> 
> Yes, that's likely because when the Debian Python policy was initially
> drafted, there was no Python 3 anywhere close to entering Debian. So
> “Python” and “Python 2” were less ambiguously conflated at that time.
> 
> Now that Python 2 and Python 3 are both commonly (and correctly)
> referred to as “Python”, we need to take more care using the terms for
> what we mean.
> 
> > Ambiguous or not, I think the policy is mostly consistent in using
> > python and python3 vice python2 and python3.
> 
> Well that's another dimension of confusion :-) The term “python2” and
> “python3” are named of commands, more than the names of languages.
> 
> I think you're right that this needs a general clean-up through the
> policy document, to consistently use:
> 
> * “python2” to refer to that command only;
> 
> * “python3” to refer to that command only;
> 
> * “python” to refer to that command (and I'd suggest deprecating it
>   where feasible);
> 
> * “Python 2” referring exclusively to that language version 2.x and no
>   other versions of that language;
> 
> * “Python 3” referring exclusively to that language version 3.x and no
>   other versions of that language;
> 
> * “Python” referring to the language implemented either as Python 2 or
>   Python 3.
> 
> > At this point I think internal consistency is probably more important,
> > so if someone wants to go through and make all the python's that
> > should be python2, etc then please send in a patch.
> 
> I'll take that on. Send it to anywhere in particular? Or I can just send
> it to this forum.

Here or a bzr branch (per my other reply) somewhere is fine.  I agree with all 
of that except the idea of deprecating /usr/bin/python.  It'll never point to 
anything other than a Python (2) version in Debian, so there's no need to 
deprecate it faster than Python (2) in general.

Scott K

[toc] | [prev] | [next] | [standalone]

#8151

Thanks for taking this on Ben,

On Jan 24, 2016, at 04:33 PM, Ben Finney wrote:

>I think you're right that this needs a general clean-up through the
>policy document, to consistently use:
>
>* “python2” to refer to that command only;
>
>* “python3” to refer to that command only;
>
>* “python” to refer to that command (and I'd suggest deprecating it
>  where feasible);
>
>* “Python 2” referring exclusively to that language version 2.x and no
>  other versions of that language;
>
>* “Python 3” referring exclusively to that language version 3.x and no
>  other versions of that language;
>
>* “Python” referring to the language implemented either as Python 2 or
>  Python 3.

I agree with all the above, though re: Scott's feedback on deprecation of
/usr/bin/python, here's my take (note, we've had these discussions many times
before ;).

Ultimately, we should be both guided by, and drive with our opinions, PEP 394
which should help keep the situation consistent across *nix distros.

https://www.python.org/dev/peps/pep-0394/

/usr/bin/python (on Debian) should never point to anything but the latest
Python 2 version *until* Python 2.7 is EOL'd upstream, meaning binary, source,
and security-only releases.  Bug fix releases (source only) are promised until
2020, and I'd wager we'll see supported security-only releases until 2025.

I would like to see scripts that are only compatible with Python 2 to be
shebanged `/usr/bin/python2` or `/usr/bin/python2.7`.  You can think of this
mostly as documentation at this point, but it does remove any possibility of
future ambiguity.

It also begins to open the door to the often discussed launcher idea someday
landing on /usr/bin/python, enabling bilingual scripts.

I think there's zero harm in this since shebang lines are generally not
user-evident.

Then there's no change to /usr/bin/python any time soon, or the fact that
invoking `python` at the shell starts the Python 2 interpreter.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8163

Ben Finney <ben+debian@benfinney.id.au> writes:

> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
>   style, markup, and language style. This should not change the meaning
>   of anything, but will change the wording of numerous passages.
>
>   My proposal for that is attached here as a Bazaar change bundle.
>
> * Address all the language around Python 2 versus Python 3 versus Python
>   general, and re-order or re-word to focus *primarily* on Python 3,
>   with Python 2 treated as the still-supported legacy system.
>
>   Once these non-semantic changes are accepted I will begin work on the
>   second stage of semantic changes.

That last sentence isn't very clear. What I intended to imply is:

The first stage is done and all its changes are in the branch, the
second stage I haven't yet started.

The set of revision in the “r411–r424” patch bundle is all intended to
be non-semantic changes, and once they're accepted I'll begin on the
second, semantic-changing, stage of work.

-- 
 \        “I don't accept the currently fashionable assertion that any |
  `\       view is automatically as worthy of respect as any equal and |
_o__)                                   opposite view.” —Douglas Adams |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8165

[Multipart message — attachments visible in raw view] — view raw

Hi Ben,

On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
>   style, markup, and language style. This should not change the meaning
>   of anything, but will change the wording of numerous passages.
>
>   My proposal for that is attached here as a Bazaar change bundle.
>
> * Address all the language around Python 2 versus Python 3 versus Python
>   general, and re-order or re-word to focus *primarily* on Python 3,
>   with Python 2 treated as the still-supported legacy system.
>
>   Once these non-semantic changes are accepted I will begin work on the
>   second stage of semantic changes.
>
> I'm maintaining a Bazaar branch for this, feel free to get it::
>
>     $ mkdir python.benfinney/ && cd python.benfinney/
>     $ bzr branch --bind http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/

Thanks for your work here, your changes look nice to me!

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#8168

Dmitry Shachnev <mitya57@debian.org> writes:

> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> > I'm planning to provide changes in two bundles:
> >
> > * Go through the whole document and tidy it up for consistency,
> >   source style, markup, and language style. This should not change
> >   the meaning of anything, but will change the wording of numerous
> >   passages.
> >
> >   My proposal for that is attached here as a Bazaar change bundle.
>
> Thanks for your work here, your changes look nice to me!

Thank you. Are you in a position to do me the favour of merging the
bundle into the repository ‘pkg-python/python-defaults-debian/’ at
Alioth?

-- 
 \         “Money is always to be found when men are to be sent to the |
  `\   frontiers to be destroyed: when the object is to preserve them, |
_o__)     it is no longer so.” —Voltaire, _Dictionnaire Philosophique_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8169

On January 26, 2016 10:32:57 PM EST, Ben Finney <ben+debian@benfinney.id.au> wrote:
>Dmitry Shachnev <mitya57@debian.org> writes:
>
>> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
>> > I'm planning to provide changes in two bundles:
>> >
>> > * Go through the whole document and tidy it up for consistency,
>> >   source style, markup, and language style. This should not change
>> >   the meaning of anything, but will change the wording of numerous
>> >   passages.
>> >
>> >   My proposal for that is attached here as a Bazaar change bundle.
>>
>> Thanks for your work here, your changes look nice to me!
>
>Thank you. Are you in a position to do me the favour of merging the
>bundle into the repository ‘pkg-python/python-defaults-debian/’ at
>Alioth?

Only one of the package maintainers can do that.  I'm very busy with $work at the moment, but I should be able to get it reviewed and merged no later than Saturday (probably Friday).

Scott K

[toc] | [prev] | [next] | [standalone]

#8170

Scott Kitterman <debian@kitterman.com> writes:

> I should be able to get it reviewed and merged no later than Saturday
> (probably Friday).

Much appreciated, thanks for the response.

-- 
 \        “When I was a baby I kept a diary. Recently I was re-reading |
  `\   it, it said ‘Day 1: Still tired from the move. Day 2: Everybody |
_o__)                  talks to me like I'm an idiot.’” —Steven Wright |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8179

On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
...
>   Once these non-semantic changes are accepted I will begin work on the
>   second stage of semantic changes.
...

OK.  Those are all accepted.  Barry Warsaw had done some changes in the -whl 
section so I made an attempt at merging what the two of you had done.

Thanks,

Scott K

[toc] | [prev] | [next] | [standalone]

#8182

Scott Kitterman <debian@kitterman.com> writes:

> On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
> ...
> >   Once these non-semantic changes are accepted I will begin work on
> >   the second stage of semantic changes.
> ...
>
> OK.  Those are all accepted.

Thank you, Scott! I'll proceed with the semantic changes that promote
Python 3 to the primary position.

> Barry Warsaw had done some changes in the -whl section so I made an
> attempt at merging what the two of you had done.

That attempt clobbered my earlier changes in that area. I'll restore
them and preserve Barry's intention.

I should have some more changes to present in a day or two.

-- 
 \      “The best mind-altering drug is truth.” —Jane Wagner, via Lily |
  `\                                                            Tomlin |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8208

On Sat, Jan 23, 2016 at 9:55 AM, Barry Warsaw wrote:

> 2.5 Module Path
>
> "Public Python modules must be installed in the system Python modules
> directory, /usr/lib/python<X>.<Y>/dist-packages.  Public Python 3 modules must
> be installed in /usr/lib/python3/dist-packages."

Side-note: does anyone know why Python puts packages in
"dist-packages", "site-packages" etc directories instead of just
"packages" directories?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#8209

On Feb 16, 2016, at 11:05 AM, Paul Wise wrote:

>Side-note: does anyone know why Python puts packages in "dist-packages",
>"site-packages" etc directories instead of just "packages" directories?

I don't remember exactly why we called it 'site-packages', but I believe it
was an evolution from the earlier ni.py module, which was where dotted module
paths first showed up in Python.

According to the HISTORY file, site-packages showed up sometime between 1.5a3
and 1.5a4, which IIRC would have been around 2001, so after Pythonlabs split
from CNRI.  If you want to read a blast from the past, here's Guido's original
essay on built-in package support added in Python 1.5, again derived from the
optional ni.py in earlier versions.

https://www.python.org/doc/essays/packages/

dist-packages was a later Debian compromise so as not to break from-source
builds installed in /usr/local with the default `make install` target.  I
think that was probably around the time I joined Canonical but wasn't working
on the Foundations team yet.  I do remember Doko and I talking about it, and
it seemed like 'dist-' was a good parallel to 'site-' (i.e. a place for the
distribution to put things).

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8210

On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote:

>I don't remember exactly why we called it 'site-packages', but I believe it
>was an evolution from the earlier ni.py module, which was where dotted module
>paths first showed up in Python.

And which had a 'site-python' directory, which was kept at least for Python
1.5 also.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8211

On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote:

> I don't remember exactly why we called it 'site-packages' ...

Thanks for the history :)

I always thought it strange to put site- in /usr/local since
/usr/local already implies site/system-wide packages. Same for dist-
since /usr already implies distribution packages. I find it weird that
site- gets used in ~/ since they are clearly user packages not
site/system-wide packages.

Any thoughts on that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#8212

On Feb 16, 2016, at 11:54 AM, Paul Wise wrote:

>I always thought it strange to put site- in /usr/local since
>/usr/local already implies site/system-wide packages. Same for dist-
>since /usr already implies distribution packages.

For as long as I can remember, a from-source 'configure && make && make
install' always put Python in /usr/local by default.  I think it was pretty
much the defacto standard for non-vendor supplied software[*] back in the days
of IRIX, SunOS, and other early *nix OSes that Python was developed on.  So it
was therefore completely natural that you'd end up with a site-packages in
/usr/local.  It was only later that the /usr/local site-packages directory
ended up on a /usr pathed distro-provided Python, which of course led to the
previously discussed dist-packages, the location of which completely mirrors
site-packages.

>I find it weird that site- gets used in ~/ since they are clearly user
>packages not site/system-wide packages.

It's all just a big ball of cruft-on-cruft with backward compatibility
preventing most cullings.  Somewhere out there, the entire world financial
system probably still critically depends on a tiny bit of Python 1.3 that
nobody has anything but the .pyc files for any more. ;)

Cheers,
-Barry

[*] I can't even call it Free Software or Open Source because it predates
those terms.  I mean, I started out sharing split shar files on Usenet with my
UUCP address.  ObGOML.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.maint.python

csiph-web