Re: Python Policy: Things to consider for Stretch
On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote: > Ben Finney writes: > > * 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. > > > > 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-deb > > ian/devel/ > Ben Finney writes: > > Thank you, Scott! I'll proceed with the semantic changes that promote > > Python 3 to the primary position. > > Those changes are now in the above branch. The summary of changes from > the commit messages: > > $ bzr log --log-format line --revision ancestor:.. > 430: Ben Finney 2016-02-02 Re-phrase version distinctions to make Python > 3 primary. 429: Ben Finney 2016-02-01 When only Python 2 is specified, just > use literal “2” major version. 428: Ben Finney 2016-02-01 Use Python 3 > examples where appropriate. 427: Ben Finney 2016-01-31 Refine some grammar > and punctuation. 426: Ben Finney 2016-01-31 Distinguish “Python” the > unversioned system versus “Python 2”. 425: Ben Finney 2016-01-30 [merge] > Merge from ‘python-defaults-debian’ mainline. > > Also attached to this message as a Bazaar patch bundle. I've merged these changes. I have a little bit of adjustment I want to do on top of it, but this helps a lot. Thanks, Scott K
Re: Python Policy: Things to consider for Stretch
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./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
Re: Python Policy: Things to consider for Stretch
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
Re: Python Policy: Things to consider for Stretch
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
Re: Python Policy: Things to consider for Stretch
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
Re: Python Policy: Things to consider for Stretch
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.
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote: > > Ben Finney writes: > > > * 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. > > I've merged these changes. I have a little bit of adjustment I want to > do on top of it, but this helps a lot. Thanks, You're welcome, and thank you for working to get this in. -- \“All opinions are not equal. Some are a very great deal more | `\ robust, sophisticated, and well supported in logic and argument | _o__) than others.” —Douglas Adams | Ben Finney
