Mailman 3 August 2014 - 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

Handling Case/Normalization Differences
by Donald Stufft Sept. 30, 2014

Sept. 30, 2014

Right now the “canonical” page for a particular project on PyPI is whatever the author happened to name their package (e.g. Django). This requires PyPI to have some "smarts" so that it can redirect things like /simple/django/ to /simple/Django/ otherwise someone doing ``pip install django`` would fall back to a much worse behavior. If this redirect doesn't happen, then pip will issue a request for just /simple/ and look for a link that, when both sides are normalized, compares equal to the name it's looking for. It will then follow the link, get /simple/Django/ and everything works... Except it doesn't. The problem here comes from the external link classification that we have now. Pip sees the link to /simple/Django/ as an external link (because it lacks the required rels) and the installation finally fails. The /simple/ case rarely happens when installing from PyPI itself because of the redirect, however it happens quite often when someone is attempting to instal from a mirror instead. Even when everything works correctly the penality for not knowing exactly what name to type in results in at least 1 extra http request, one of which (/simple/) requires pulling down a 2.1MB file. To fix this I'm going to modify PyPI so that it uses the normalized name in the /simple/ URL and redirects everything else to the non-normalized name. I'm also going to submit a PR to bandersnatch so that it will use normalized names for it's directories and such as well. These two changes will make it so that the client side will know ahead of time exactly what form the server expects any given name to be in. This will allow a change in pip to happen which will pre-normalize all names which will make the interaction with mirrors better and will reduce the number of HTTP requests that a single ``pip install`` needs to make. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

6 19

Accepting PEP 440: Version Identification and Dependency Specification
by Nick Coghlan Sept. 2, 2014

Sept. 2, 2014

I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software. The PEP is available in the usual place at http://www.python.org/dev/peps/pep-0440/ It's been a long road to get to an implementation independent versioning standard that has a feasible migration path from the current pkg_resources defined de facto standard, and I'd like to thank a few folks: * Donald Stufft for his extensive work on PEP 440 itself, especially the proof of concept integration into pip * Vinay Sajip for his efforts in validating earlier versions of the PEP * Tarek Ziadé for starting us down the road to an implementation independent versioning standard with the initial creation of PEP 386 back in June 2009, more than five years ago! Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

7 7

Re: [Distutils] Packages that have problems being installed from wheels
by Joost Molenaar Sept. 1, 2014

Sept. 1, 2014

On Aug 27, 2014 8:50 AM, "Paul Moore" <p.f.moore(a)gmail.com> wrote: > > tl; dr; If you know of a project that can't be successfully installed > with "pip wheel proj; pip install /path/to/the/wheel.whl" can you let > me know the details? Both Ansible and Fabric want to put stuff in <virtualenv>/usr/share, which doesn't work from a .whl file but does from the sdist. AFAICT, you need to spell out the data files redundantly in MANIFEST.in *and* setup(data_files=...), or the wheel won't contain the files. I've been meaning to write up a test case to demonstrate the problem for a good while, but haven't got around to it yet. HTH, Joost Molenaar

5 6

defining requirements on pypi
by Brett Graham Aug. 28, 2014

Aug. 28, 2014

Hi, I feel like these are stupid questions but I cannot seem to find a straight answer. In brief, 1) what is egg-info/requires.txt used for? 2) how do I properly define requirements for pypi? The details are: I'm updating some packages on pypi and am having difficulty defining requirements. One of the packages in question is: pypi.python.org/pypi/jsui I'm initially defining the requirements in a requirements.txt that then gets parsed in setup.py and install_requires gets set to the contents of requirements.txt. Some of the output from python setup.py sdist build is below. The resulting requires.txt in jsui.egg-info is: flask wsrpc However, when I upload this to pypi with "python setup.py sdist upload" I'm not seeing these requirements listed nor does pip installing the package install the requirements. Thanks for your help. ==== python setup.py sdist build partial output ==== running sdist running egg_info writing requirements to jsui.egg-info/requires.txt writing jsui.egg-info/PKG-INFO writing top-level names to jsui.egg-info/top_level.txt writing dependency_links to jsui.egg-info/dependency_links.txt reading manifest file 'jsui.egg-info/SOURCES.txt' writing manifest file 'jsui.egg-info/SOURCES.txt' running check warning: check: missing required meta-data: url creating jsui-0.0.1 creating jsui-0.0.1/jsui creating jsui-0.0.1/jsui.egg-info making hard links in jsui-0.0.1... hard linking README -> jsui-0.0.1 hard linking setup.py -> jsui-0.0.1 hard linking jsui/__init__.py -> jsui-0.0.1/jsui hard linking jsui/serve.py -> jsui-0.0.1/jsui hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info Writing jsui-0.0.1/setup.cfg Creating tar archive removing 'jsui-0.0.1' (and everything under it) running build running build_py

5 6

Undefined symbol when loading a library using dlopen
by Jerome Fuselier Aug. 28, 2014

Aug. 28, 2014

Hello, I'm trying to wrap a C++ library which uses dlopen to load a dynamic library and I don't manage to get rid of an "undefined symbol" error. I tried to simulate my problem with a simpler example so hopefully someone may be able to tell me what I'm doing wrong. I have a file func.cpp which provides 2 functions : func.cpp: int simple(void) { return 12; } int call_lib(void) { int res; void *handle = dlopen("/home/jerome/Test/libDyn.so", RTLD_NOW); if (!handle) { return -1; } dlerror(); char* err = 0; int (*fun_dyn)() = (int (*)())dlsym(handle, "fun_dyn"); if ( (err = dlerror()) != 0 ) { dlclose(handle); return -1; } res = (*fun_dyn)(); dlclose(handle); return res; } It is created like that: $ g++ -Wall -g -fPIC -c -o func.o func.cpp $ ar rcs libFun.a func.o I have a dynamic library which is called from call_lib() which depends on libFun.a: libDyn.cpp: #include "func.hpp" int fun_dyn(void) { return simple(); } It is created like that: $ g++ -Wall -g -fPIC -c -o libDyn.o libDyn.cpp $ g++ -Wall -g -fPIC -shared -o libDyn.so libDyn.o I'm using swig to wrap the libFun.a library with this mylib.i interface file: %module mylib int simple(void); int call_lib(void); Then I'm using this setup.py file to create the Python module: from distutils.core import setup, Extension mylib = Extension("_mylib", sources=['mylib.i'], language="c++", extra_link_args=['-rdynamic'], libraries=["Fun", "dl"], ) setup(name="MyLib", platforms=["Linux"], ext_modules=[mylib], py_modules = ["mylib"]) It's a simplified example but when I compile everything I get this error in Python: >>> import _mylib >>> _mylib.call_lib() failed to open shared object file /home/jerome/Test/libDyn.so: undefined symbol: simple If I do a nm _mylib.so I see that the symbol simple is present in the library so I'm wondering why dlopen doesn't see it when it tries to load the library. I know I can recompile libDyn.so to link libFun.a but this would means I would need to recompile all the plugins provided for the library I'm trying to wrap and that's not really a solution for my project. Sorry for the long email. I can provide a tar.gz of the source code if needed. Thanks for your help Jerome

2 1

Packages that have problems being installed from wheels
by Paul Moore Aug. 28, 2014

Aug. 28, 2014

tl; dr; If you know of a project that can't be successfully installed with "pip wheel proj; pip install /path/to/the/wheel.whl" can you let me know the details? One of the longer-term goals of the introduction of wheels was to split the build and install steps for a package - specifically, in pip, to restrict "pip install" to installing from wheels, and when no wheel is available, to (transparently) run "pip wheel" on the sdist followed by "pip install on the generated wheel". During a discussion yesterday, I realised that I don't know how close we are to that goal. So I'm looking for information on packages which don't install properly from wheels at the moment. If anyone has examples of packages where replacing "pip install foo" with "pip wheel -w /tmp/xxx; pip install /tmp/xxx/*.whl" does not result in an equivalent install, could they post them here with details of how & why they fail? Things I already know about (but would like specific examples): 1. Post-install steps included in setup.py. That should be covered by the support in Metadata 2.0. I'd also be interested in how much of an issue omitting the postinstall would be in practice (for instance many such steps just set up "Start Menu" type shortcuts, which are not essential for the package to be usable). 2. Actually, that's the only one :-) Things that should not be a problem (but might be): 1. Numpy (and the scipy stack) need better tagging facilities for wheels - but that wouldn't matter for a wheel that's built, used, then thrown away. 2. Some things are complex to build - but I don't know of any cases where building a wheel is *more* complex than installing, and I don't see how it could be, in theory. 3. Projects that customise setup.py so much that they aren't compatible with setuptools and bdist_wheel. Such projects are quite probably already incompatible with pip (which injects setuptools when running setup.py anyway) and so not relevant for this discussion. But if any do work with "pip install" but not "pip wheel", I'd like to hear about them. Thanks in advance for any information. Paul

7 9

requirements on pypi: what is egg.info/requires.txt?
by braingram Aug. 27, 2014

Aug. 27, 2014

Hi, I feel like these are stupid questions but I cannot seem to find a straight answer. In brief, 1) what is egg-info/requires.txt used for? 2) how do I properly define requirements for pypi? The details are: I'm updating some packages on pypi and am having difficulty defining requirements. One of the packages in question is: pypi.python.org/pypi/jsui I'm initially defining the requirements in a requirements.txt that then gets parsed in setup.py and install_requires gets set to the contents of requirements.txt. Some of the output from python setup.py sdist build is below. The resulting requires.txt in jsui.egg-info is: flask wsrpc However, when I upload this to pypi with "python setup.py sdist upload" I'm not seeing these requirements listed nor does pip installing the package install the requirements. Thanks for your help. ==== python setup.py sdist build partial output ==== running sdist running egg_info writing requirements to jsui.egg-info/requires.txt writing jsui.egg-info/PKG-INFO writing top-level names to jsui.egg-info/top_level.txt writing dependency_links to jsui.egg-info/dependency_links.txt reading manifest file 'jsui.egg-info/SOURCES.txt' writing manifest file 'jsui.egg-info/SOURCES.txt' running check warning: check: missing required meta-data: url creating jsui-0.0.1 creating jsui-0.0.1/jsui creating jsui-0.0.1/jsui.egg-info making hard links in jsui-0.0.1... hard linking README -> jsui-0.0.1 hard linking setup.py -> jsui-0.0.1 hard linking jsui/__init__.py -> jsui-0.0.1/jsui hard linking jsui/serve.py -> jsui-0.0.1/jsui hard linking jsui.egg-info/PKG-INFO -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/SOURCES.txt -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/dependency_links.txt -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/requires.txt -> jsui-0.0.1/jsui.egg-info hard linking jsui.egg-info/top_level.txt -> jsui-0.0.1/jsui.egg-info Writing jsui-0.0.1/setup.cfg Creating tar archive removing 'jsui-0.0.1' (and everything under it) running build running build_py

1 0