Mailman 3 October 2009 - Distutils-SIG

Two fixes (at last)
by Greg Ward April 29, 2018

April 29, 2018

Hi all -- at long last, I have fixed two problems that a couple people noticed a while ago: * I folded in Amos Latteier's NT patches almost verbatim -- just changed an `os.path.sep == "/"' to `os.name == "posix"' and added some comments bitching about the inadequacy of the current library installation model (I think this is Python's fault, but for now Distutils is slavishly aping the situation in Python 1.5.x) * I fixed the problem whereby running "setup.py install" without doing anything else caused a crash (because 'build' hadn't yet been run). Now, the 'install' command automatically runs 'build' before doing anything; to make this bearable, I added a 'have_run' dictionary to the Distribution class to keep track of which commands have been run. So now not only are command classes singletons, but their 'run' method can only be invoked once -- both restrictions enforced by Distribution. The code is checked into CVS, or you can download a snapshot at http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz Hope someone (Amos?) can try the new version under NT. Any takers for Mac OS? BTW, all parties involved in the Great "Where Do We Install Stuff?" Debate should take a good, hard look at the 'set_final_options()' method of the Install class in distutils/install.py; this is where all the policy decisions about where to install files are made. Currently it apes the Python 1.5 situation as closely as I could figure it out. Obviously, this is subject to change -- I just don't know to *what* it will change! Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Package versioning
by Timothy Docker April 29, 2018

April 29, 2018

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller April 29, 2018

April 29, 2018

3 2

Distribute sprint #2, next sunday
by Tarek Ziadé Nov. 3, 2009

Nov. 3, 2009

Hey, We will have a sprint sunday afternoon, starting at 3 pm in Berlin/Germany. If you are interested you can join online in the irc (#distutils on Freenode) or in Berlin of course. This sprint will continue the work we've started on the 0.7 branch. If you have worked during the first sprint and you can't make it sunday, please make sure your worked was commited in the Distribute repository with notes so we can continue. Cheers Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

1 1

PEP 390 - new format from setup.cfg
by Tarek Ziadé Nov. 3, 2009

Nov. 3, 2009

Hey this is the PEP for setup.cfg, as requested : http://www.python.org/dev/peps/pep-0390 Please comment, Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

14 101

Re: [Distutils] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Chris Withers Oct. 31, 2009

Oct. 31, 2009

Paul Moore wrote: > 2009/10/20 Ian Bicking <ianb(a)colorstudy.com>: >> Well, I wanted to move it off python-dev, and I didn't really feel >> like moving it onto distutils-sig because I felt the debate was not >> particularly important to introduce the confusion of a half-started >> thread. > > Sorry, I hadn't realised it was on python-dev rather than > distutils-sig. You're right in that case. > >> My point is the bdist_win installers work fine for both your use case, >> Paul, and Chris' use case, so there's no real conflict. > > OK, and yet people still seem to argue for eggs rather than > bdist_wininst, and projects provide eggs rather than bdist_wininst. > Something's not working here, even though logic says it should. Well, speaking only for myself, I never use bdist_wininst packages because they do no dependency management. If I release a package that has no external dependencies, I'll stick a bdist_msi or bdist_wininst if asked, but it's rarely asked for. From that I infer that most people use tools like buildout or pip to manage installation, even on Windows. Again, as a package consumer, I prefer one cross-platform package management method for Python packages, regardless of what operating system I happen to be working on at the time... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

9 17

distribute and buildout: best practices?
by Reinout van Rees Oct. 28, 2009

Oct. 28, 2009

What's the current best way to use both distribute and buildout? Apart from the bootstrap + apparently needed change in buildout, I've got the following questions: - Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it. I tried putting distribute in there, but I seemed to get less problems with leaving it at setuptools. - Should just globally installing distribute be enough? Everything ought to keep working. It does lead to a bunch of runtime warnings in buildout, however. (But Tarek has targeted that problem for the upcoming 0.6.4 :-) - Do I need to change buildout's bootstrap already? Doing that tries to change my global setuptools, for which you need to sudo. And it also forces everyone else using that buildout to switch (which in itself is OK). - From my experiments (not exhaustive! no real debugging!) it seems that the only safe way is to first install distribute globally before touching a buildout that brings in distribute. Is this to be expected? Reinout -- Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"

11 38

[issue88] urllib2.splituser
by Jürgen Hermann Oct. 28, 2009

Oct. 28, 2009

New submission from Jürgen Hermann <Juergen.Hermann(a)1und1.de>: setuptools/package_index.py throws an AttributeError in Python 2.3 due to auth, host = urllib2.splituser(netloc) It either needs the following monkey patch, or simply use splituser from urllib. import urllib import urllib2 if not hasattr(urllib2, 'splituser'): # setuptools wants to import this from urllib2 but it's not # in there in Python 2.3.3, so we just alias it. urllib2.splituser = urllib.splituser ---------- messages: 441 nosy: jhe priority: bug status: unread title: urllib2.splituser _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue88> _______________________________________________

1 0

Re: [Distutils] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Chris Withers Oct. 27, 2009

Oct. 27, 2009

[adding in disutils-sig and leaving this message intact as that's where it belongs] Paul Moore wrote: > 2009/10/20 Ian Bicking <ianb(a)colorstudy.com>: >> FWIW, I don't think there's a real conflict here. My understanding is >> that wininst installers can be treated as installable packages that >> don't *have* to go through the system package manager, so they are >> both installable system-wide and installable much like an egg or >> tarball is (you can't drop the wininst installer into the path >> directly like you can an egg, but that doesn't seem to be a >> widely-held goal). > > The conflict lies in the fact that I want the features that > bdist_wininst installers give me (integration with add/remove programs > and uninstallation) [1]. If every project offers a bdist_wininst > installer, I'm happy. But Chris isn't unless they provide his > preferred format (I'm not sure if Chris has a concrete suggestion, or > he's just speculating at the moment) as well. Huh? I don't really care how packages are installed, provided they end up in a consistent format on disk. I'm not sure how a bdist_wininst installer is going to make sure a package's dependencies are met though... > I'm assuming (based on experience with eggs) that projects won't > routinely provide all possible formats. Hence my contention that a > single format is necessary. > > Having multiple package management systems that consume that format is > fine by me. But easy_install can consume bdist_wininst installers, so > the evidence is that there's more needed for a single format to emerge > than has been done so far (otherwise why isn't bdist_wininst that > single format right now?) Because not everyone runs on Windows? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

tracking requested vs dependency installs in PEP 376 metadata
by Carl Meyer Oct. 27, 2009

Oct. 27, 2009

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I propose adding a bit to the PEP 376 metadata that indicates whether a package was installed by user request or as a dependency of another package. This would allow (un)installer tools to intelligently remove orphaned dependencies, if they so choose. There might be questions about the details of such an uninstaller feature, but I'm not intending to discuss that here. The metadata itself is simple enough to track, and seems like it ought to be included for its future usefulness. I propose adding a metadata file REQUIRED within the .egg-info directory. The presence of this file indicates that the user specifically required this distribution. The absence of the file indicates that the distribution was installed as a dependency. The contents of the file are not used. For the API, I propose adding a "required" property to the Distribution class, which would be True or False based on the presence or absence of the REQUIRED file. I've added a demo implementation to a fork of Tarek's pep376 repo on bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/ Thoughts? Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKzhXFFRcxmeyPUXIRAvPkAJ4+bBPrt0fvYi2u/LhpLo2KS9ImfACfX9oq 5gab4TRuuWWUknOO0SK2E6I= =Dm+n -----END PGP SIGNATURE-----

12 37