Mailman 3 October 2010 - Distutils-SIG

Two fixes (at last)
by Greg Ward 29 Apr '18

29 Apr '18

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 29 Apr '18

29 Apr '18

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 29 Apr '18

29 Apr '18

3 2

[buildout] branches languishing? (site-packages and distutils scripts)
by Chris Withers 02 Apr '12

02 Apr '12

Hi All, I'm wondering what the state of play is with the following branches: reinout-scripts gary-4-include-site-packages What more needs to happen for these to get merged to trunk and a release made? cheers, Chris

10 28

[PEP376] RECORD line separator
by Atsushi Odagiri 09 Jun '11

09 Jun '11

Hi I read pep276, and I have a question. This PEP says that line separator of RECORD file is `os.separator`. and 'bdist-*' command will also create RECORD file. Does it even work with the package which doesn't depend on the OS like bdist_egg ? I think that file format should not depend on os environment and good choice is CRLF. It's standard line separator as used in email headers. by aodag -- /* Atsushi Odagiri http://blog.aodag.jp mailto:aodagx@gmail.com */

2 1

docs/ vs doc/
by anatoly techtonik 23 Feb '11

23 Feb '11

Hi, I see that distutils2 promotes storing documentation in docs/ directory while Python sources use Doc/ I'd like to see this changed before distutils2 is released beta. In my projects checkouts there are 80 project that use doc/ directories. Among these are: - subversion - hg - sphinx - trac - scons - twisted docs/ directory is used by 61 project, the most famous are: - xalan - fop - moinmoin - cmd2 - googlecl There are some arguments for 'doc/': 1. there is no plural for 'documentation' 2. bin/ is a common name for storing executables, although there is plural for 'binary' 3. we still use src/ instead of sources/ Any thoughts/objections? -- anatoly t.

9 19

Building Python (Re: An observation on how system packagers and developers can be friends)
by Jim Fulton 29 Nov '10

29 Nov '10

On Thu, Oct 28, 2010 at 6:08 PM, Tres Seaver <tseaver(a)palladion.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/28/2010 05:54 PM, Benji York wrote: >> On Thu, Oct 28, 2010 at 5:44 PM, Tres Seaver <tseaver(a)palladion.com> wrote: >>> Heh, "untar + CMMI into a non-system prefix" works for me. ;) >> >> +1 with the small addition of "after making sure the dev dependencies Python >> sniffs out to build modules for (zlib, crypto bits, etc.) are available." > > Heh, agreed. That bites me on about every third machine I set up for > the first time. An advantage of automating building of clean Python's with system packaging tools is that you can make sure the sane dependencies are present. My clean Python RPM spec file lists the libraries I need before a build, so I can't accidentally build a crippled Python due to forgotten libraries. Of course, you also end up with a binary package that is quicker to install on similar hosts than building on each host. It would be nice if Python's standard build required more dependencies and had options to turn them off is desired, rather than sniffing to tell whether they are there and silently building badly. Jim -- Jim Fulton

2 1

mercurial update problem with pip
by Fabian Sturm 21 Nov '10

21 Nov '10

Hi, I am using pip version 0.3.1 on Ubuntu Linux 9.10 to install django-piston in a virtualenv. Since I need a specific version of django-piston I have the following entry in the requirements.txt file: -e hg+http://bitbucket.org/jespern/django-piston@dc0ee00d3bfc#egg=django-piston The first time the install works fine with pip but on the second time I get the following error: Command hg fetch -q failed with error code 255 Exception information: Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/pip.py", line 252, in main self.run(options, args) File "/usr/lib/python2.6/dist-packages/pip.py", line 408, in run requirement_set.install_files(finder, force_root_egg_info=self.bundle) File "/usr/lib/python2.6/dist-packages/pip.py", line 1741, in install_files req_to_install.update_editable() File "/usr/lib/python2.6/dist-packages/pip.py", line 1486, in update_editable version_control(self.url).obtain(self.source_dir) File "/usr/lib/python2.6/dist-packages/pip.py", line 2942, in obtain call_subprocess(['hg', 'fetch', '-q'], cwd=dest) File "/usr/lib/python2.6/dist-packages/pip.py", line 3543, in call_subprocess % (command_desc, proc.returncode)) InstallationError: Command hg fetch -q failed with error code 255 If I run "hg fetch -q" manually in the django-piston repository I get: abort: working dir not at branch tip (use "hg update" to check out branch tip) mercurial is at version 1.3.1. Any ideas what is wrong and how I get it to work? Thanks a lot, Fabian ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 1

An observation on how system packagers and developers can be friends
by Jim Fulton 05 Nov '10

05 Nov '10

Periodically, in various venues, we discuss the challenges of deploying applications with or in spite of system packaging of Python and system packaging philosophies. (Note that I'm mainly talking g about deploying applications, as opposed to individual Python packages.) In my experience, the conversation usually unfolds with developers (like me:) snarkely saying how annoyed we are and systems packagers (and administrators) explaining all of the rules they have to follow and that we should follow too. In practice, I think the result is usually that developers make an end-run around system packaging system, either building in production, or by building system packages that bundle dependencies to get needed control. The result is that at least some of the system packagers goals are subverted. In my experience, both sides have legitimate goals, but the problem is rarely, if ever, approached from the point of view of recognizing both sets of goals coming up with a (probably new) solution that addresses both sets of goals. (Note that "doing things the way I've always done them" is *not* a valid goal. :) I believe that solutions that address both sets of goals are possible and even practical, but it has to start with a consideration of the underlying goals. Jim -- Jim Fulton

9 11

Re: [Distutils] easy_install not choosing source package on pypi
by P.J. Eby 29 Oct '10

29 Oct '10

At 11:58 AM 10/29/2010 -0700, Tom Miller wrote: >Great, thanks. I guess there's no way to tell easy_install to look >for a specific extension? Or to use the file hosted at pypi? If you're the person doing the installing, then of course you can manually specify a URL, or use "easy_install googlecl==0.9.11" to force the right file to be selected. However, if you're the package author and want to fix it for everybody, you can either rename the non-applicable file, or remove the Home Page link from the PyPI pages that it's on. (You'd have to remove it from every version you've ever published on PyPI, though, even if it's an inactive one.)

1 0