Le mardi 07 octobre 2008 à 16:51 -0400, Phillip J. Eby a écrit : > >If you write a tool to do that, why not make it simply move files > >properly and let the code locate them, instead of adding yet another > >layer on top of the existing stuff? The tool will not be more > >complicated this way. > > I'm not sure I follow you. What I'm proposing is that: > > 1. A BUILDS "manifest" for a project should list the files included > in the project by what "kind" of file they are, as well as by > inter-file relationships (e.g., "these 3 files are part of Python > package 'foo.bar' within this project, and they are static data used > at runtime but not read or written"). > > 2. BUILDS-compatible install tools will be free to install those > files wherever they like (or create .debs, .rpms, etc. that do), and > use symlinks so that the installed project can find them in the > places that the developer wanted to find them. > > Is this what you're asking for? Because it's what I've been trying > to say we should do.
What I am afraid of is that, by adding just another layer, you will introduce new problems while fixing existing ones. Currently we already have a hard time maintaining a symlink farm, and adding a second symlink farm on top of it is not going to make things more understandable (currently, package maintainers already have a hard time understanding how to deal with Python modules) nor more reliable. The first kind of issues I can think of is that dpkg handles symlinks to directories very badly, so you’re likely to run into issues that have to be dealt with by hand by maintainers. I haven’t thought about it much, but I have the feeling that other things will break. In the end, if you are designing a new packaging specification and a new tool, I think you’d better take this as an occasion to do the right thing instead of adding this new layer. > For example, if Debian needs metadata that's not in the core BUILDS > metadata, it should be possible within BUILDS to include it, so that > it can be contributed upstream. Likewise, it should be possible for > a BUILDS install tool to use a third-party supplement to get that > data, so that when you're initially porting a project, you could > write a file with the additional data while doing the initial port, > then submit that file upstream. If there is a need for Debian-specific metadata, it will go in the debian/ directory. It looks interesting to integrate it upstream only if it is relevant for other distributors. > Less flippantly, our goal here is to have something that has a better > cost/benefit ratio for adoption by a Python developer who has not > seen any pressing need for autoconf in their life to date. And if > somebody wants to make a BUILDS tool to generate autoconf sources > from a project manifest, then great! No, no. Please don’t :) But if you can express in the project manifest the same flexibility as with autoconf (or even the tenth of it, we don’t need *that* much flexibility), that should be enough. > >BTW, I would consider it a good approach to try bringing BUILDS on par > >with the autotools capabilities. These tools have serious drawbacks, but > >they were written with the ability to work for distributors in mind. > > Sure. I like stealing designs and requirements definition from > mature projects, even if you might argue that I chose poor role > models for setuptools. (Java and OSGi.) > > However, since autotools compatibility isn't a goal in itself, I > think I'll leave it to those people who have interest/experience to > propose what specific autotools features they'd like to see in > BUILDS, and the use cases they have for them. If I were to just skim > the docs trying to figure that out, I might think that something cool > in it is actually useful, or vice versa. ;-) So, it's better here I > think to hear from experienced users such as yourself. There is no use in being compatible with the autotools, the point is about stealing good ideas. The first thing that comes to mind, and that we already discussed at large, is the ability to specify at install time where data, documentation, manual pages and so on have to go. Another thing that I consider a good design (when expunged of the useless stuff in it) is the config.h file. It is a file that is generated at configure time and which contains macros you may need inside your code: package version, installation directories, enabled features, etc. What some Python projects using autoconf are doing, and I’d like to see in BUILDS, is the generation of a config.py file at installation time. It would be useful to specify install-time stuff like installation directories, optional features and installation parameters. For example it could contain: version = "1.2.3" builddate = "Tue 7 Oct 2008, 23:12 +0100" templates_dir = "/usr/share/foobar/templates" has_libamazing = True # _foobar.so is built with libamazing support page_footer = "Powered by foobar" For Python-only packages, you can easily ship a default config.py file that works without installation: version = get_version_from_changelog () templates_dir = os.path.join(os.path.basedir(__file__),"templates") page_footer = "Foobar (development version)" By doing such a thing, you are guaranteed to obtain easily the data you need from within the Python application: import config template = file(os.path.join(config.templates_dir), "foo.template") I may be biased because I’m used to work like this, but I find this easier for both the developer and the distributor. In my personal experience, it is also more reliable. Another thing from the autotools that I’d like to see is seamless integration with pkg-config, for modules with C extensions. Bonus points for being able to use not only compilation flags and installation paths, but also macros you need to use inside the code (they could go in config.py). I’ll tell you if I can think of other things. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig