Mailman 3 February 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

distribute 0.6.10 and convert_2to3_doctests
by Barry Warsaw 23 Apr '10

23 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I have a Python package called 'munepy' <https://launchpad.net/munepy> which provides yet another flavor of enums. I'm working on the code for various reasons and I thought I'd take the opportunity to learn how to support both Python 2 and 3 from the same code base. I've updated the code so that it supports Python 2.6 at a minimum, and made it 'python -3' clean. I've switched it from using setuptools to using distribute. I was looking at this page: http://packages.python.org/distribute/python3.html and it seems very cool that distribute can help make my life easier by allowing me to support both Python 2 and 3 from the same code base. I set use_2to3=True in my setup.py and indeed % python3 setup.py test (On Ubuntu 9.10) runs 2to3 over my .py files. However, my doctests are in separate .txt files and I cannot seem to get the right incantation for convert_2to3_doctests. In the root of my source directory, my doctest lives at munepy/docs/README.txt, so I put this in my setup.py: ... use_2to3 = True, convert_2to3_doctests = [ 'munepy/docs/README.txt', ], ... but I never see that the README.txt is ever 'fixed'. Indeed, the test fails because of a syntax error when the doctest tries to print something using Python 2 syntax. I'm clearly not using this setup argument correctly, but I can't tell where I'm going wrong. How do you use convert_2to3_doctests? TIA, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLRRn+AAoJEBJutWOnSwa/U78P/06neAOc4cbeaKty7OX1AvUo 9QKwNrmH5U/spbvvThPKCl+XXPDJdD4K40zCSaq98vGXdjxIgBapCvQi3/lUBtKM M5CBVJvsbJnaeAZUjUS2EZ+CLXkMAmWA/8znmo3xsGJ+8+F77Wb9iTwobQpQqmWJ z43BLaiT62fzWqC4vsBjG6JMF0VZZZ51IRrzD48lasYItHa4cUQa/brC8jwGUhE4 060zo+cof5UvbMRNP0OU69p0M5PztOtszLKHaOhD8EsAF8r1PWtOT2oGpij8jLst GBp82J+JOlgWiEFSmVLaSOl/0D0193ut+PtHLCLDOJ9sVXgIKv4RvWMip1/0W1bB btneAIUJ/CFxCJuBcadkGtwS9geuaM+ma2rlYOpwTBncBEZx9XVPOxnEuCyUSrSo 03QXZ6xxOKf1Xepg3AjDD2KSxrAZHoG4aLVGdxqFyAebpC9hiKYRrLswe5mg/ycj eo5lpKjGplL5Md0O9ZgJmqk0UH4CVZy7Imrv8BMQcMCZLkbs42FnMXtXVWEVQ9qm iA3T54Yi5dOZB56JjnkftyS15in8W5OiV1X78WtblQ7/f5oR1UXq72mZU3k+3nrX kxWfzsHAo1v34+WHUagmYZqLYtm/zFT+zHwoyzzMcWpJSTH8WIOud9IuSkg5gA3S B2iMITFAZnXKzB644gIP =GqOL -----END PGP SIGNATURE-----

7 20

Re: [Distutils] RFC: Barely minimal CI + tests + packaging in Python WAS: Guidelines for where to put tests & how to package them
by P.J. Eby 11 Mar '10

11 Mar '10

At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote: >PS: BTW, how could I trigger easy_install(ation) at a given point >while implementing a distutils command, and let the command perform >further actions if deps are installed correctly ? Setuptools' "Distribution" object has a method for fetching dependencies. See setuptools' "test" command for an example. (This doesn't install the dependencies globally, just drops eggs into the build directory. But they're there and available to be reused for installation in a later phase, under normal circumstances.)

4 12

Fwd: The fate of Distutils in Python 2.7
by Tarek Ziadé 01 Mar '10

01 Mar '10

FIY (I didn't cross-post to make it easier for following the threads) ---------- Forwarded message ---------- From: Tarek Ziadé <ziade.tarek(a)gmail.com> Date: Fri, Feb 26, 2010 at 10:44 PM Subject: The fate of Distutils in Python 2.7 To: Python-Dev <python-dev(a)python.org> Hello, This is a follow-up of the Pycon summit + sprints on packaging. This is what we have planned to do: 1. refactor distutils in a new standalone version called distutils2 [this is done already and we are actively working in the code] 2. completely revert distutils in Lib/ and Doc/ so the code + doc is the same than the current 2.6.x branch 3. leave the new sysconfig module, that is used by the Makefile and the site module The rest of the work will happen in distutils2 and we will try to release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the goal is to put it back in the stdlib in Python 3.3 Distutils in Python will be feature-frozen and I will only do bug fixes there. All feature requests will be redirected to Distutils2. I think the easiest way to manage this for me and for the feedback of the community is to add in bugs.python.org a "Distutils2" component, so I can start to reorganize the issues in there and reassign new issues to Distutils2 when it applies. Regards Tarek -- Tarek Ziadé | http://ziade.org -- Tarek Ziadé | http://ziade.org

3 6

Re: [Distutils] layout and setup.py for packaging documentation
by P.J. Eby 01 Mar '10

01 Mar '10

At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote: >Can this be simpler? Yes. Don't install docs with your package. People who want them installed locally can just download your source install or use easy_install -e. Also, if your module is popular enough that people make Linux system packages for it, they will make sure the docs get put in a blessed install location. Python doesn't currently have a blessed install location for documentation, though perhaps it *should* have one in distutils2.

5 8

layout and setup.py for packaging documentation
by Jean Daniel 28 Feb '10

28 Feb '10

Hello, I am looking for the simplest way to package the html files related to a pure python module. At this point, I would like to just embed them in the source tarball generated by distribute and leave it to a debian or fedora package to install them. I would like a source tarball laid out as the following: wordish-1.0.2/ setup.py wordish.py docs/ index.html command-ref.html So far, I tended to use a single file python module because there was no need for more and I wanted to keep it simple: wordish/ setup.py wordish.py test_wordish.py The setup.py is minimal: setup( py_modules = [ 'wordish' ], ... ) But If I want to include docs, I must use the package_data command which expects a package name. So I think that to embed documentation in the source tarball, I should change the way I lay out the source repository to something like : wordish/ setup.py wordish wordish.py __init__.py docs/ index.html command-ref.html test_wordish.py The corresponding setup.py would be setup( packages = [ 'wordish' ], package_data = {'wordish':['docs/*']}, ... I am not sure this is the right way to do it, just to include documentations in the tarball: - the package_data requires a package name, so I turn my pure python module into a package just for this reason - package_data requires the data directory to be inside the package directory even though the html files are generated from doc sources located elsewhere, - there is an extra level of directory to get to the Python sources module, it is my_virtualenv/wordish/wordish/wordish.py which does not add much. Can this be simpler? Thanks for your help,

1 0

Re: [Distutils] [TIP] Guidelines for where to put tests & how to package them
by P.J. Eby 26 Feb '10

26 Feb '10

At 02:27 PM 2/26/2010 -0500, Olemis Lang wrote: >test_suite is ( supported | introduced | defined ) by >setuptools.comand.test.test class > > > Is it required to be a > > callable > >yep No. test_suite is to be an object recognized by the test_loader as convertible to a unittest TestSuite. For example, a module, TestCase subclass, etc. You are probably thinking of the test_runner option, not test_suite. >test command performs test discovery (as a last recourse AFAICR, /me >cc-ing to P.J. Eby because probably he has further updates ;o) using a >loader: setuptools.comand.test.xxx Setuptools' test loader will scan modules and packages, but you still have to tell it where your top-level test package or module is. (The test_suite.) >BTW, I am strongly -1 for using the discovery protocol introduced in >2.7 (AFAICR), specially because it collides with test_suite and many >other arguments ... so it would be very nice when defining packaging >conventions, layout ... not to enforce the use of that protocol, so >that if another discovery is used then it could still be compatible >with the more abstract good practices. (all this said from my selfish >position, I confess) I'm not sure what you're talking about here; I'm not much in the loop for what's going on with distutils updates, and even more so for unittest updates.

1 0