Mailman 3 December 2009 - Distutils-SIG

Re: [Distutils] Python people want CPAN and how the latter came about
by Laura Creighton Dec. 26, 2009

Dec. 26, 2009

In a message of Fri, 25 Dec 2009 19:43:24 +0900, David Cournapeau writes: >I think many people within >the group of disatisfied Pypi users would be happy to have less >packages for a better overall experience. Aside from the fact that the word you want is _fewer_ not _less_ when you are talking about a countables, I suspect this statement is true. But I don't see any relationship between 'forcing people to download their packages' and 'giving users a better experience'. And I see one major use case where forcing people to download their packages simply will not happen. Many commercial organisations have a policy that they, and only they host their own code. And they will not be willing to change this policy even if you convice them that it is in their interest to Open Source some of it, or perhaps the python bindings to some of it. How do we want to interoperate with these people and their code? Laura

5 5

buildout examples clarification
by Jeff Kunce Dec. 24, 2009

Dec. 24, 2009

I am using the buildout page on pypi as a reference http://pypi.python.org/pypi/zc.buildout What is the python shell used for the examples? I can follow what is going on, but I'm not familiar with some of the functions used. For example: >>> write(sample_buildout, 'recipes', 'mkdir.py', ...) Sorry if this is a silly question, but I'm stumped. Thanks.

4 5

Is it possible to configure __requires__ and load_entry_point for console_script?
by Dowding, George Dec. 23, 2009

Dec. 23, 2009

Hi, I have a setup() that uses a version control change number to set the version of the package. Part of the package includes some console_script directives. When the scripts are generated the __requires__ and load_entry_point will be set to the exact version of the package. I would like to have it set to something less restrictive. Is that possible? Example change = '12345' setup( name='my-project', version='my-project.0.1.dev-r%s' % version, entry_points={'console_scripts': ['my_script = my_module:main']}) Will generate my_script __requires__ = 'my-project==0.1.dev-r12345' import sys from pkg_resources import load_entry_point sys.exit( load_entry_point('my-project==0.1.dev-r12345', 'console_scripts', 'my_script')() ) I would like it to change the requirement such that the script will run with 'my-project==0.1.dev' regardless of the exact change number. -- Thanks, George A. Dowding

1 0

Swig build_py ran before build_ext
by Jari Pennanen Dec. 22, 2009

Dec. 22, 2009

Hi! I have old/new problem, once mentioned in 2004 at this same mailing list ( http://mail.python.org/pipermail/distutils-sig/2004-March/003807.html ) but surely that implementation is bad... But the problem persists, I use SWIG and had to Google all over to only find out build order cannot be changed. Someone should implement build_order keyword argument to setup, e.g.: setup(..., build_order=['build_ext', 'build_py']) If some orders are missing, like in above example: build_clib, build_scripts, they would be appended as last. Anyways, the point is make the build order customizable through setup keyword.

3 4

Specifying eggs and build manifest ?
by David Cournapeau Dec. 22, 2009

Dec. 22, 2009

Hi, I wonder if there is any interest in the current distribute effort to specify some low-level commonalities outside the distutils code for interoperation. In particular, I had two things in mind: 1 Formally specifying the egg format (and versioning it !) - or is egg format outside distribute goal ? 2 Formally specifying something like a build manifest which would be used for installation. I think the first point is self-explanatory. Concerning the second point, the current way of installing things in distutils is a bit too ad-hoc to my taste, and could be fixed inside distutils to make it easier to interoperate with other methods (be it native OS methods or other python-related tools). Right now, distutils install things from a list of files, but this only contains the target location for some kind of files. What about the following kind of format instead (or in complement for backward-compatibility): - split the flat list into a list of "typed" sections, where type would be e.g. data, python files, extensions, scripts, etc... - for each section, specify both the source and target directory. - the format should be easy to parse/produce, and versioned. The rationale is that such a format would enable the following: - it becomes easier to post-process files at install time, with different methods for each type - such a format could form a basis to produce "conventional" install, eggs and other kind of installers, including convertion between them. Assuming this idea fits into what people involved in distribute are doing, I would be willing to propose a more formal description - I already have the implementation in my own project toydist, where I use build manifest to do explicit install and eggs/wininst conversion. cheers, David

3 3

Re: [Distutils] Specifying eggs and build manifest ?
by P.J. Eby Dec. 22, 2009

Dec. 22, 2009

At 10:24 AM 12/22/2009 +0900, David Cournapeau wrote: > 1 Formally specifying the egg format (and versioning it !) - or is >egg format outside distribute goal ? FYI: http://peak.telecommunity.com/DevCenter/EggFormats

2 1

Not picking Older version eggs
by devyan parmar Dec. 21, 2009

Dec. 21, 2009

Hi, I am using buildout for my project development as well as for deployment. which makes process easy and help in repeatability. but facing one problem while choosing particular versions of eggs while running buildout. i have eggified my python packages and releasing version wise. i have created "versions.cfg" where i mentioned all my project related packages with proper version. it's working fine for latest eggs version. but if i wants to choose older version egg from my package server, It takes latest only. even after specifying in versions.cfg also. following attributes am using in my buildout.cfg [buildout] newest = false prefer-final = true allow-picked-versions = true extends = version.cfg preferences.cfg versions = versions to avoid this i am deleting existing packages from my eggs folder and rerunning buildout. Please suggest me here... Thanks Regards Devyan Parmar

2 1

Finishing PEP 345
by Tarek Ziadé Dec. 21, 2009

Dec. 21, 2009

Hi, While PEP 386 is waiting to be accepted in python-dev, I'd like to finish PEP 345 so we can propose it right after PEP 386 is (hopefully) accepted. The remaining point I can see is about : Repository-URL, Repository-Browse-URL, Bug-Tracker-URL. As Ian suggested I propose to change these three fields to: Project-URL (multiple-use) : A string containing an URL for the project and a label for it. separated by a comma Example:: Bug Tracker, http://bitbucket.org/tarek/distribute/issues/ This field, like Requires-Dist, can be present multiple times. The label of the URL is preferrably unique but there will be no control of this unicity. Although the label is limited to 32 signs so the developer stay concise. The URL is a valid browsable URL. (http/ftp/https). PyPI could then use these URLs on the project page like this: <a href="http://bitbucket.org/tarek/distribute/issues/">Bug Tracker</a> Any thoughts ? Tarek -- Tarek Ziadé | http://ziade.org

3 6

Packaging of files, which aren't in the package root folder
by Lukas Hetzenecker Dec. 21, 2009

Dec. 21, 2009

Hello, i have the following folder structure: <application> INSTALL Changelog LICENCE <src> main.py <module 1> module.py <module 2> modile.py Is it possible to create a setup.py script which copies INSTALL, Changelog and LICENCE also in the installation folder (by default /usr/lib/python2.6/site- packages/application)? I have this script: from distutils.core import setup setup(name='application', version='1.0', packages=['src', 'src.module1', 'src.module2'], package_data={'' : ['Changelog', 'HACKING', 'INSTALL', 'LICENSE', 'LICENSE.icons-oxygen', 'README.icons-oxygen', 'TODO']}, scripts=['application-wrapper'] ) I also tried it so: from distutils.core import setup setup(name='application', version='1.0', packages=['application', 'application.module1', 'application.module2'], package_dir={'application': 'src/'}, package_data={'application' : ['Changelog', 'HACKING', 'INSTALL', 'LICENSE', 'LICENSE.icons-oxygen', 'README.icons-oxygen', 'TODO']}, scripts=['application-wrapper'] ) But this did also not work. I think another way would be to use data_files instead of package_data - but this copys the files to /usr/bin by default, and I don't know the actual application directory - or would this be possible? (If you suggest to move the content of the src/ directory to the root folder, or to copy the INSTALL and LICENCE files to the src folder, this wouldn't work. The src folder is actually not named src/ but pc/ and there is also a folder for the part of the mobile phone - and I want the LICENSE and INSTALL file in the root directory to not confuse the users, but I only want to install the content of the pc/ (or as in this simple example, the src/ folder) on the computer.) Thanks for any help, Lukas

4 14

Distribute testing
by ssteinerX＠gmail.com Dec. 20, 2009

Dec. 20, 2009

Tarek, We recently talked about incorporating the testing scheme I started in distutils-buildbot directly into the release path for Distutils to avoid issues like the ones with the most recent release. I am putting this out on the list for comments; I'm NOT interested in bikeshedding this to death. Anyone else is welcome to do their own project if they feel strongly enough about it. I'm going to take opinions into account but I want to have the tool built before the next release, not the next millennium release of Python. The way I started with the project in distutils-buildbot (http://bitbucket.org/tarek/distutils-buildbot/ smoke-and-mirrors branch, bin/smoke2.py, bin/smoke2.cfg, and bin/smoke_base_products.cfg) was to assume a brand new system e.g. a newly initialized Cloud Server and to build out everything necessary to run the tests under Python 2.4, 2.5, 2.6, 2.7dev, 3.1, and 3.2dev. While this approach will be fine when we move it to building on-demand buildbots, it is much too time consuming both in development time and real-time processing to use for this release cycle. It would be much better (for now) to just make sure you're running it on a machine that can do the job. The main goal is to come up with a simple way to run as many full-scope tests i.e. from install through full test-suite on as many large products, with as many versions of Python as practical. What we had originally started was to build and run the test suites for (spec'd in bin/smoke_base_products.cfg): Twisted numpy tarek_extensions warped I had stopped where it reads the configuration files and knows on what versions of Python to test which products. At this point, I'd like to move this into Distribute proper and get it into the "pre-release" test process. So... First, we need to decide where to put the testing sub-project. I'm asuming it can just live in the /tests subdirectory, maybe with a subdir to hold this whole project as its own module. Here's what I'd like to see it do: Run pre-test checks i.e. verify that the machine is capable of running the tests: 1> Assume that `python2.4`, `python2.5`, `python2.6`, `python3.1` will invoke a properly set up Python interpreter. This is beyond the scope of this project; might be taken up at a later time. 2> Create a simple way to verify installed utilities before proceeding with tests (anyone have one of these around?). Something like: ASSERT(`nosetests -V` == `nosetests version 0.11.1`) 3> Allow a certain amount of corrective action to be able to be taken to satisfy the assertions above (like, install nose version 0.1.11 from PyPi, for example) for each supported version of Python. Then: for each product to be tested: for each Python version this product is to be tested on: install the product run its test suite record any failures Pretty simple, but will avoid any of the sorts of issues we just had with the most recent release, is very easy to add new products to (just add a configuration section), and can be easily moved out to the buildbots when it does what we want. Comments etc. gladly accepted as long as there are no bikeshedding tools (hammers, paint-brushes, Erlang) in hand. Thanks, S aka/Steve Steiner aka/ssteinerX

2 2