Distutils-SIG June 2014

distutils-sig@python.org

29 participants
28 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

2 years, 11 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

2 years, 11 months

[Distutils-sig] distutils charter and interscript

by John Skaller

2 years, 11 months

windows permissions on bdist egg scripts, data?

by Erik Purins

Hey there, I’m using python 2.7/setuptools 3.6 to build an egg of my code (checked into perforce) using my setup.py. This egg gets installed into a virtualenv. On osx/darwin this works fine. On windows, the bdist creates scripts and data whose permissions are read-only (attrib+r), and they cannot overwrite themselves in a subsequent build of that egg. Similarly, re-installing a new egg using virtualenv fails because the installed egg’s scripts and data are not writable. I thought it might be that when checked out from perforce, the permissions stayed read-only during the build of the egg, so I set all the files in my module to be read-write before building. Even when the original source files’ permissions are all set to read-write, the generated bdist egg script/data content end up becoming read-only. Couple of questions. 1. Since it works fine on osx, it seems like a bug in the windows implementation of setuptools. Is this known behavior, is there a reason for setting this on scripts/data on windows? 2. Is there a hook in the bdist egg build process I can use to set the attributes of the files correctly when the bdist egg is made? How/where should I define this in my setup.py? Kind regards, -e

6 years, 7 months

zc.buildout & Docker container images

by Nick Coghlan

Hey all (but especially the zc.buildout users), With zc.buildout being used to define repeatable application deployments, and Docker images acting as a way to snapshot entire execution environments for ease of deployment on any environment than can run a container (which is basically any modern Linux at this point, or will be once CentOS 7 is available), has any experimented with using zc.buildout from a Dockerfile to define an image? If yes, is it written up anywhere? If not, is anyone intrigued enough by the idea to considering trying it out and writing up the results as a blog post somewhere? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 years, 9 months

question

by batoot zilzel

hi am blind and am python programmer but i can't write the codes from python idl should i use notepat ++ and some plugins to write and run the codes cause the python idlis not accessible with blind and with the screen reader i hope to hear from you as soon as thanks regards

6 years, 9 months

setuptools wish list

by lunasspecto＠gmail.com

Hi folks. I'm new to the list and don't mean to impose, but I've been following some of the recent developments of the PyPA and I'm wondering if the unreasonable expectations I have for Python packaging are about to come true, or if there's a simple workaround to achieve some of these goals in the meantime. In building the Python 3 application I'm currently working on I have the end goal of supporting Windows users, Debian-based system users, and maybe Fedora users with installable distributions they can install without worrying about dependencies. I won't consider my packaging efforts to be successful if somebody using one of these systems has to manually install Python 3.4 or PyQt5 before they can install my application. Ultimately I'd also like to package my application as a standalone OS X app, but I don't have access to an OS X system right now. After some wrestling with cx_Freeze in Python 3.4 on Windows 7 in a VirtualBox machine, I've been able to put together a satisfactory Windows test distribution bundled with all its dependencies. setuptools will produce an rpm package, but I wouldn't know how to make sure the package depends on PyQt 5 and the QScintilla plugin for PyQt 5, so Fedora users can install my application without having to know they need these dependencies. I can't list PyQt5 or PyQt5.Qsci in the "install-requires" setuptools option because, as far as I understand, this option is only for listing packages that can be installed by pip. I have managed to set up a Debian packaging infrastructure such that I can build a Debian binary package with the command "dh --with python3 binary-indep", but I haven't figured out how to include an XDG menu entry in the package, and I consider this a deal-breaker. Of course, setuptools doesn't currently handle XDG menus at all. So my wish list for setuptools or a similar tool is: * Automated XDG menu entry generation * Some way to handle dependencies that can't be installed by pip * Automated generation of Debian binary packages good enough to be accepted into the repositories * Automated generation of rpm packages with all the right dependencies (For all I know this could exist already, but considering the way dependencies are currently handled by setuptools I really doubt it) * In a perfect universe, easy cross-building functionality, so I could produce a standalone Windows executable or an OS X app from the comfort of Xubuntu.

6 years, 10 months

Setuptools 4.0 and 4.0.1 superseded by 3.8.1

by Jason R. Coombs

Due to the regression reported in [Setuptools #218]( https://bitbucket.org/pypa/setuptools/issue/218/setuppy-develop-fails-with-…), I've removed all versions of Setuptools 4.x and closed that branch. I will continue to explore the underlying issue, [Setuptools #210]( https://bitbucket.org/pypa/setuptools/issue/210) to seek a proper solution, possibly without backward incompatibility. Please use Setuptools 3.8.1 or later. If another backward-incompatible release is made for anything other than issue 210, it will tagged as Setuptools 5.0, bypassing 4.0 altogether. Regards, Jason

6 years, 10 months

Is there a chance for directory globs supported in 'data_files' ?

by Egor Berdnikov

Hi all, Some time ago there was a movement towards deprecating MANIFEST.in and adding directory support to setup()'s 'data_files'. Is there actually something against implementing directory globs in 'data_files'? I'm a little bit lost among current 'sdist' and 'bdist_rpm' options regarding directories. I'm searching for a solution for 'bdist_rpm' errors like this one: "can't copy 'lib/directory/*': doesn't exist or not a regular file". Related part of the documentation, a mail list discussion, and a bug: https://docs.python.org/2/distutils/setupscript.html#installing-additional-… https://mail.python.org/pipermail/distutils-sig/2009-April/011308.html http://bugs.python.org/issue5302 -- Egor

6 years, 10 months

ctypes and shared libs, and wheels, oh my!

by Chris Barker

Folks, I'm trying to help figure out how to do binary wheels for a package that relies on ctypes and a bundles shared lib (dll, .so. etc) The trick here is that the python code is quite version and platform independent: py2 and py3, version 2.7 and 3.3+ (I think) (it's py_enchant, if anyone is interested: http://pythonhosted.org/pyenchant/) So the trick is that the binary wheel will be platform dependent, but not the code itself, so ideally we'd have one wheel, that for instance (and teh case at hand) should work on any OS-X box version 10.6 and above, with a any of python2.7, 3.3, 3.4 (an up?) Usually, a binary wheel involves compiled extensions, and thus is tied to a particular python version -- so this is an odd case. We tried: pyenchant-1.6.6-py2.py3-none-macosx_10_6_intel.whl which seems to be saying: any version of python2 or python 3, but only on macosx 10.6 but trying to install that on my machine (py2.7, os-x 10.6) gives: pyenchant-1.6.6-py2.py3-none-macosx_10_6_intel.whl is not a supported wheel on this platform. (side note: it would be really great if that could be a more useful message -- what part of the file name didn't match? I know that's a trick, as there is a whole pile of heuristics to go through, but maybe a way to dump that process would be helpful...) Now, this may, in fat be tied to CPython (I have no idea if ctypes is available on pypy or jython or IronPython...). So I tried: pyenchant-1.6.6-cp27-none-macosx_10_6_intel.whl that does, indeed, install on my system. Also: pyenchant-1.6.6-cp27.cp33-none-macosx_10_6_intel.whl works. As 2.7 is really the only py2 that much matters, no biggie, but is there a way to get 3.3 and 3.4 and ??? all at once (I don't have py3 on that machine, so didn't test that...) So: how should this be done? Is the above the best option there is? Thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

6 years, 10 months

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 2014