Mailman 3 November 2012 - Distutils-SIG

License for distribute_setup.py?
by Eric McDonald 24 Nov '12

24 Nov '12

Hi, The distribute project web site said that this is the mailing list for it, so I hope I'm asking my question in the right place. I've googled around some (including the archives for this list) and looked through some of the files at https://bitbucket.org/tarek/distribute/src, but have been unable to find out what the licensing terms for the 'distribute_setup.py' script, which is made available to be bundled with other project's sources, are. My research discovered that sources for the original PEAK setuptools can be under either the PSF or Zope licenses; I assume that a derivative work, such as distribute (?), would continue to be licensed along those lines. As 'distribute_setup.py' is in the same repo as the distribute sources, one might guess that it would also have the same license. But, since this is a file intended to be used in other projects, I think a clarification on the issue would be nice. (Sorry, if I missed something obvious.) Thanks, Eric P.S. Not trying to create a ruckus about licensing. I am just trying to catalog all "alternative" licenses in effect for a project that I am working on.

2 2

Generating two Debian packages with stdeb
by Edward Ekelund 22 Nov '12

22 Nov '12

Hi, I'm wondering if there is a way to generate two .deb-files from a single setup.py file. Or, if that's not possible, generate deb files from custom-named setup.py files, e.g. client_setup.py & server_setup.py. The reason I'm asking is that I need the source code to reside in the same root folder. I'd also like to keep a clean folder structure, something along the lines of this: /test-program client.py server.py server_adapter.py setup.py tests/ unit/ client_unit_test.py server_unit_test.py function/ client_function_test.py server_function_test.py etc/ init.d/ server server.conf usr/ bin/ client server I'd like to generate client.deb, containing [client.py, usr/bin/client], and server.deb, containing [server.py, server_adapter.py, etc/server.conf, etc/init.d/server, user/bin/server]. Also server.deb should be depend on client.deb. After copying the stdeb folder to /test-program/ I've tried running python client_setup.py --command-packages=stdeb.command bdist_deb It fails however, since it seems that one of the dh-scripts is hard coded to look for setup.py. I have no idea how to configure setup.py to generate two .debs. Thanks, Eddie

2 4

Re: [Distutils] distlib and data files => resources ?
by a.cavallo＠cavallinux.eu 21 Nov '12

21 Nov '12

I'd be expecting these files under /usr/share/<appname> and being read only... I don't agree with "Data files should never be installed to package directories"... LFHS is not a religion. I can see cases where is not appropriate. The main difference could be a library vs an application case: they have clearly different requirements (so I'm expecting the application global config files to be under /etc). Someone mentioned different scenarios (app vs library, user vs system integrator vs developer etc I hope this helps Thanks Antonio On Wed 21/11/12 04:21, "PJ Eby" pje(a)telecommunity.com wrote: > On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren > wrote: > > On 19 Nov, 2012, at 20:26, PJ Eby wrote: > > > > > > Data files should never be installed to package directories. But > Im not aware of any good reason why resource files should ever be > installed anywhere *else*. > > To be (too) snarky: because the FHS says so. > > Less snarky, Linux distributors try to keep simular files together > (for example storing all gettext translations together in > /usr/share/locale). To play nice in such an enviroment Python > packages would have to install resource files outside of the python > package and into the FHS specified directory structure. > Consider the example of a web page template containing embedded > Python code. Is that a data file containing code, or a code file > containing data? Where does the FHS say it goes? > > What if its not embedded Python, but an embedded DSL interpreted by > the package it goes with? > > What if its not a page template, but a precompiled SQL grammar? > (Such as was distributed with the "gadfly" package, many a year ago.) > > These are the kind of files I mean by "resources". If somebody > wants to support gettext or similar localization, then obviously they > should declare the files data -- or better yet, as part of an explicit > localization category. > > The whole point of "resources" is that its a catch-all for static > data thats more convenient to treat as a standalone source file than > to inline as a huge triple-quoted constant in a .py file. ;-) > > >

1 0

distlib and data files => resources ?
by Tarek Ziadé 21 Nov '12

21 Nov '12

Hey I was reading this : http://distlib.readthedocs.org/en/latest/overview.html#what-was-the-problem… and I thought I should bring up that distutils2 has implemented a way to define data files that can be installed in the "right" places on the target system. "right" here being what the linux distros decides, or the default win location etc. There is a description here: http://alexis.notmyidea.org/distutils2/setupcfg.html#resources I think it's a better system than the data files that are located/and stay in the python package, maybe it would be interesting not to lose it. Cheers Tarek

13 24

Accept just PEP 426 (x-post from python-dev)
by Vinay Sajip 20 Nov '12

20 Nov '12

Daniel Holth <dholth <at> gmail.com> writes: [referring to "Provides-Dist"] > Mostly it seems a bit silly to have so much conversations about parts of the > pep that remain unchanged from previously accepted versions... I don't agree with the suggestion that we shouldn't discuss it because it was accepted in a previous version. Perhaps it didn't receive the right scrutiny at that time, but since it hasn't been implemented, it's reasonable to discuss it. ISTM that implementing it as suggested in the PEP can lead to certain problems, since it is a multi-valued field. If it is left in, then something should be said in the PEP about the potential difficulties and if/how they can be resolved. The difficulties I am talking about relate to dependency resolution. Given the current definition of Provides-Dist, it is possible for a package A on PyPI to "Provide" all of e.g. "A (1.0)", "B (1.2)" and "C (1.5)", and it is also possible for packages B and C on PyPI to provide the same (or slightly different) versions of logical packages of A, B, and C. This will likely lead to the need for a sophisticated dependency resolver because the dependency graph can get quite convoluted. (Remember, we might need to do this resolution when removing packages as well as when installing them.) I know there are SAT solvers and such, but I'm not sure we need that level of sophistication, or whether its complexity cost is outweighed by any benefit. Remember, we are managing fine without multi-valued Provides-Dist, and while a case has been made for virtual packages and forks (which just require a single-valued field), no compelling case has been made for bundling packages in general (I understand that such requirements might sometimes arise in certain corporate environments, but they don't seem to be a mainstream use case). Hence, no strong case has been made for a multi-valued "Provides" field. If we have a good index and packaging infrastructure, there is no general need for packages to bundle other packages, unless those bundled packages are changed in some way to suit the bundler's needs. In that case, I don't know how you could be sure that a bundled "A (1.0)" hasn't diverged from the equivalent package on PyPI. The "Provides" seems essentially useless in a metadata index, since if, when asked to install D which has a dependency on A, you would download and install A to resolve it rather than B or C, and I can't see when you would want to query the index to say "who provides A?" and then use some heuristic to pick e.g. B or C, rather than A. distlib currently contains support for the multi-valued "Provides", but I'm not confident that will work as expected given pathological cases like the example I suggested, without getting "complicated" in the Zen of Python sense. I'm not convinced that the maintenance burden of a complicated solution is worth the heretofore unnecessary ability to bundle stuff in arbitrary ways. Regards, Vinay Sajip

1 0

Re: [Distutils] [Python-Dev] Accept just PEP-0426
by Daniel Holth 20 Nov '12

20 Nov '12

The section could definitely be much clearer. How about: Provides-Dist (multiple use) Each entry contains a string naming a requirement that is satisfied by installing this distribution. This field *must* include the project identified in the ``Name`` field, optionally followed by the version: Name (Version). A distribution may provide additional names, e.g. to indicate that multiple projects have been merged into a single distribution or to indicate that this project is a substitute for another. For instance distribute (a fork of setuptools) could ``Provides-Dist`` setuptools to prevent the conflicting package from being downloaded and installed when distribute is already installed. A distribution that has been merged with another might ``Provides-Dist`` the obsolete name(s) to satisfy any projects that require the obsolete distribution's name.

1 0

Re: [Distutils] Welcome to the "Distutils-SIG" mailing list
by hu xiaoying 16 Nov '12

16 Nov '12

Hi member: I have a problem now. when i running command of bdist_rpm to convert project of python development to rpm, the specification of rpm does not list the dependencies package. anyone can tell me which wrong i encounter? BR huxiaoying

1 0

console_script does not install scripts in some packages?
by Václav Šmilauer 15 Nov '12

15 Nov '12

Hi everybody, I posted this question at http://stackoverflow.com/questions/13271085/console-scripts-entry-point-ign… without getting response, so I turn to the ML. I am using setuptools 0.6c11 under Windows (64bit, mingw64). I have a trouble with setup.py - I use entry_points={'console_scripts':['woo = wooMain.main']}, which works fine under Linux, but creates no scripts at all under Windows (64bit, using mingw64). Curiously, some other packages, which also use console_scripts (ipython, for instance), do get their .exe's created just fine. The relevant part of setup.py is below. I attach "setup.py install" log, in case it is informative. Curiously, it says "writing entry points to core/main\woo.egg-info\entry_points.txt", but this file does not even get installed with the egg. Coud you suggest a way to debug that (such as running setup.py more verbose)? Or suggest a package with very simple setup.py which also uses console_scripts and actually works -- Cheers, Vaclav > from setuptools import setup > > wooModules=['woo.'+basename(py)[:-3] for py in glob('py/*.py') if > basename(py)!='__init__.py'] > execFlavor='' > > setup(name='woo', > version=version, > package_dir={'woo':'py','':'core/main','woo.qt':'gui/qt4','woo.pre':'pkg/pre','woo.gts':'py/3rd-party/pygts-0.3.1'}, > packages=( > ['woo','woo._monkey','woo.tests','woo.pre'] > +(['woo.qt'] if 'qt4' in features else []) > +(['woo.gts'] if 'gts' in features else []) > ), > py_modules=wooModules+['wooOptions','wooMain'], > ext_modules=[ > Extension('woo.'+cxxInternalModule, > sources=cxxSrcs, > include_dirs=cppDirs, > define_macros=cppDef, > extra_compile_args=cxxFlags, > libraries=cxxLibs, > library_dirs=libDirs, > extra_link_args=linkFlags, > ), > ], > # ignored under windows? > http://stackoverflow.com/questions/13271085/console-scripts-entry-point-ign… > entry_points={ > 'console_scripts':[ > 'woo%s = wooMain:main'%execFlavor, > 'woo%s-batch = wooMain:batch'%execFlavor, > ], > }, > zip_safe=False, > ) >

2 1

why not link modules against msvcrt.dll istead of versioned msvcr*.dll? (mingw32)
by Václav Šmilauer 15 Nov '12

15 Nov '12

Hi everybody, I recently (inconclusively) discussed on the mingw-w64 mailing list why are compiled modules linked to msvcrt90 (depending on python build) rather than to msvcrt. A compiled module was crashing (the DLL would not load with "invalid access to memory and such") with msvcr90, while it works just fine with msvcrt. My understanding (based on http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx, http://msdn.microsoft.com/en-us/library/ms235460.aspx and my aforementioned experience) is that loading two MSVC runtimes at the same time is asking for trouble. Dependency Walker shows me that python27.dll itself is linking against msvcrt.dll, but distutils.cygwincompiler will link against msvcrt90 nevertheless. This means both end up loaded. OTOH I suppose there is a good reason why msvc version detection exists, but I am just ignorant of it and would like to ask here. Cheers, Vaclav <http://msdn.microsoft.com/en-us/library/ms235460.aspx>

4 5

Re: [Distutils] [Catalog-sig] [Python-Dev] accept the wheel PEPs 425, 426, 427
by Ronald Oussoren 14 Nov '12

14 Nov '12

On 13 Nov, 2012, at 17:21, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > Le Tue, 13 Nov 2012 16:10:30 +0100, > Ronald Oussoren <ronaldoussoren(a)mac.com> a écrit : >> >> On 13 Nov, 2012, at 16:00, Daniel Holth <dholth(a)gmail.com> wrote: >>> >>> I want to remove distutils from the standard library. >> >> Why? Distutils may not be perfect, but is usable for basic packages. >> It could even be enhanced to support these peps and be even more >> useable, although patches for that would run into the self-imposed >> freeze of distutils development. > > It wouldn't be totally unreasonable to start a project named > "distutils2" to build the next-generation distutils library. > > Oops :-) Or carefully enhance distutils itself. Rewriting distutils in one go seems to be too ambitious with the limited resources available to do so. Ronald

3 3