Distutils-SIG June 2012

distutils-sig@python.org

20 participants
30 discussions

by Greg Ward

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

3 years, 9 months

Package versioning

by Timothy Docker

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 years, 9 months

[Distutils-sig] distutils charter and interscript

by John Skaller

3 years, 9 months

error in windows 7 installation

by Manuel López

Hello Everybody: I am trying to install distribute-0.6.25 in a windows 7 machine. I have python 2.7.3 in 32 bits, although the machine is 64 bits. I installed the 32 bit python version because I want to install ipython and there is no 64 bit builds of the Windows installer for ipython. In any case, upon installing disuitils with python setup.py install I get the following error error: C:\manuel\prog_red\python\distribute-0.6.25\distribute-0.6.25\setuptools\cli-32.exe: No such file or directory Any help will be greatly appeciated. Thanks, Manuel -- Manuel López Mariscal Depto. de Oceanografía Física/CICESE malope(a)cicese.mx

7 years, 8 months

distribute broken Python 3.3.3

by Jim Fulton

https://bitbucket.org/tarek/distribute/issue/289/distribute-broken-with-pyt… I'm gonna try to work around it in buildout 2 by monkey-patching distribute. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

9 years, 6 months

Self Introduction and Getting Hands On

by Bohuslav Kabrda

Hi all, I recently came upon Tarek's blogpost [1] about converting Python packages to rpm specfiles. I have pretty good knowledge of this, as I am a Fedora package maintainer and Python is one of my main responsibilities. I have always wanted to become a Python developer and becoming part of distutils-sig and trying to give a helping hand with RPM related stuff is probably a good entry point for me :) To introduce myself, I work at Red Hat as a package maintainer for dynamic languages, I am author of the new Fedora-used pyp2rpm [2], [3], which tries to do exactly what Py2RPM is supposed to be. (Well, it's not perfect, but it can do 90 % of the work, usually. So far, it doesn't work with distutils2, but I'll probably be working on that when Python 3.3 gets released.) I also have some minor not-yet-released projects in Python, I work with Django and I'm just a Python enthusiast. In Fedora, I am a maintainer/comaintainer of both Python and Python3, Django and another 15+ (and growing) set of packages. Thanks for reading this through :) I'm looking forward to working with - and learning from - all of you. -- Regards, Bohuslav "Slavek" Kabrda. [1] http://ziade.org/2011/03/25/bdist_rpm-is-dead-long-life-to-py2rpm/ [2] http://pypi.python.org/pypi/pyp2rpm [3] https://bitbucket.org/bkabrda/pyp2rpm

9 years, 6 months

working with different requirements depending on python version

by Chris Withers

Hi All, While trying to debug another problem, I re-ran some Jenkins jobs for two of my packages, which promptly failed under Python 2.5: http://jenkins.simplistix.co.uk/job/testfixtures-buildout/ http://jenkins.simplistix.co.uk/job/checker-buildout/ Now, the issue here is that zope.interface 4.0 and above no longer supports Python 2.5: http://jenkins.simplistix.co.uk/job/checker-buildout/PYTHON=2.5,label=linux… http://pypi.python.org/pypi/zope.interface/4.0.0 That's fine, but I'd like the above projects to continue 2.5 support for the time being. The simple solution would be to add a versions section to the buildout here: https://github.com/Simplistix/checker/blob/master/buildout.cfg ...and pin the versions in the tox.ini here: https://github.com/Simplistix/checker/blob/master/tox.ini ...however, that doesn't give the correct result. The version requirement is "use the latest version of all packages that work with the Python version under test" and the changes I've suggested would mean that on Python 2.6 and 2.7, the latest version of zope.interface wouldn't be used. What makes this even more "interesting" is that zope.interface isn't a direct requirement of either of these projects, it's a dependency of a dependency in both cases. How have other people solved this? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

9 years, 6 months

conventions or best practice to choose package names?

by Benoît Bryon

Hi, I am looking for a convention (i.e. kind of PEP) about package names: "how to choose a good package name". I couldn't find a PEP which gives guidelines about it. PEP 8 gives some guidelines about "syntax" of package names. I found articles like "Rules of thumb" section of http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and…. But I was looking for something more "official". And thus, I was thinking of a PEP, or something similar. Scope: * we have tools to create and distribute packages. Not covered by this thread. * we have tools to create namespace packages. Not covered by this thread. * we have conventions about "syntax" of module names in PEP 8. Not covered by this thread. * do we have conventions, or at least guidelines, to choose a name for a package? I'm not to write this guide here (I'm not an expert about it), but, if such a PEP or documentation doesn't exist, here are some considerations to start: * The Zen of Python tells "There should be one-- and preferably only one --obvious way to do it." * http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and… seems interesting * maybe http://guide.python-distribute.org/specification.html#naming-specification is a cool place * maybe http://docs.python.org/dev/packaging/ is the right place for that kind of information * We should cover both simple packages and namespace packages. * I guess some teams or communities already have such conventions. As an example, does the Plone community have one? * I feel there are too much de facto standards on Pypi: as an example Plone community uses namespaces like "plone.app.theming", whereas Django community uses "django-*" pattern, there are also many "pyramid_*" packages... * We should cover public packages published on Pypi, but also public packages published on online repositories like Github, and also private (personal or corporate) packages. * I know we cannot migrate existing package names. * We could recommend something for new packages. Here are quotes seen in a recent thread about PEP 420 (http://mail.python.org/pipermail/import-sig/2012-May/000631.html), which make me believe a convention would be useful. Notice that, in fact, I discovered PEP 420 while searching for a PEP about "how to choose a good namespace". Le 13/05/2012 19:25, PJ Eby a écrit : > Regarding the nesting issue and persuading Django developers to use > namespaces, I would note that there isn't any reason for namespaces to > be deeply nested in the first place. By convention, top-level > namespace packages should be the name of a project or its sponsoring > organization, which means there is rarely a need for deep nesting. > Even cases like zope.app and peak.util are rare: usually a project or > organization will have only one such "miscellaneous" namespace with > lots of separately-distibuted components. > > (After all, the main reason to *have* a namespace package is to have > separately-distributed subpackages. So, self-contained packages don't > need to have namespaces of their own, almost by definition.) > > Anyway, what I've noticed is that when people want to deeply nest > namespaces, it's usually because they're trying to share a namespace > across organizations, like making a shared 'net.*' namespace. The > idea of namespaces isn't for that kind of categorization, though, it's > for *ownership*. If two developers are fighting over where to put > something in a category hierarchy, it's a sign that they need to be > working in different namespaces, with each developer staking a claim > to a *top-level* package -- like OSAF's osaf.*, Zope Corporation's > zc.* (vs. the community project's zope.*), and so on. > > When developers use namespaces for project/ownership distinction, the > resulting package hierarchies can be pretty much as flat as you like. If I had to explain it to another Python developer, I wish I could give him an hyperlink and say "read and follow the convention". Le 13/05/2012 20:56, "Martin v. Löwis" a écrit : > In Java, people apparently want that because they get these deeply > nested directory hiearchies (org/apache/commons/betwixt/expression). > It's apparently possible to condense this into > org.apache.commons.betwixt/expression (which isn't a shorter string, > but fewer cd commands / explorer clicks / .svn folders). > > I predict that people will start using PEP 420 in the reversed-domain > fashion also, so we eventually might end up wanting something like > this for Python. Could we anticipate namespace usage? At least for some "simple" things that already are de facto standards. As an example, I guess we could state about "reasonable maximum namespace depth", because on Pypi there is not many packages with more than 3 levels. Regards, Benoit

9 years, 6 months

zc.buildoutsftp

by Jim Fulton

If you don't use zc.buildoutsftp on Windows, please ignore :) Does anyone use zc.buildoutsftp on windows? There is some windows support that I added several years ago, presumably because someone sent me a patch. I don't use zc.buildoutsftp on Windows myself. When I wrote, zc.buildoutsftp, it had no automated tests, because I couldn't figure out a sane way to write automated tests for it. Recently, I've written mock-based tests, but these tests are unix-ish-specific. I know they'll fail on Windows. I can't say I really care. :) I'd rather have half-way decent tests that fail on windows than no tests anywhere. I've endeavored to write the code in a platform-independent manner, but without tests, it's easy to screw up. If anyone is using windows, and is willing to help at least make sure the new revision works on windows or is willing to help factor the tests to run on Windows, then I'm happy to work with them. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

9 years, 6 months

patch distutils to look into .dist-info directories

by Daniel Holth

https://bitbucket.org/dholth/distribute/changeset/0c805a76aa61 Or replacing entry_points for distutils2-style distributions with itself. Is there a name for distutils2-style distributions? (things with a .dist-info directory)? Daniel Holth

9 years, 6 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG June 2012