Re: [Distutils] distlib updated - comments sought
I looked at the documentation and can't completely follow what you are doing, although I was told in another email that the issue I raised was being addressed in pkg_resources. Here is what I need: I'm trying to build an rpm package from a Pypi tar.gz. The tar file contains several files and subdirectories. I need to map them as follows: a. Send the package modules to /usr/lib/pythonx.x/site-packages/name_of_pkg b. Send the executable command scripts to /usr/bin or /usr/sbin as appropriate c. Send any readme files, license files, doc directories, example directories, test directories, and other such files/directories to /usr/share/doc/name_of_pkg d. Generally, send the various files to places prescribed in the Filesystem Hierarchy Standard for Unix/Linux. I can't completely see how I would do this using what is described in the distlib documentation. Stan Klein On Fri, October 5, 2012 6:00 am, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Date: Thu, 4 Oct 2012 22:28:01 +0000 (UTC) From: Vinay Sajip <vinay_sajip@yahoo.co.uk> To: Distutils-Sig@Python.Org Subject: [Distutils] distlib updated - comments sought
I've updated distlib as follows:
1. I've added support for the equivalent of "pkg_resources.resource_filename" for returning a true filesystem path for a resource. I've added info about this in the "Distlib's design" document, though the reference API has not been fully updated - I thought I'd see if there was any feedback about the approach I've used. Code and tests have been added, though.
2. I've added the PyPI client code from distutils2 in distlib.pypi. I only tweaked it a little to run under 2.x and 3.x from a single code base, ensuring that all the tests passed. I hope to update it with better support for finding archives not hosted on PyPI, using hints.
I'm also considering the following changes, which I'd like some feedback on:
* Merging the distlib.depgraph package into the distlib.database package, as they are fairly interlinked (e.g. adding requires() and required_by() methods to Distribution).
* Removing depgraph.main() and its test, because I don't think it belongs in the library layer, but is better implemented as a utility script.
Please let me have your comments.
Regards,
Vinay Sajip
Stanley A. Klein <sklein <at> cpcug.org> writes:
I looked at the documentation and can't completely follow what you are doing, although I was told in another email that the issue I raised was being addressed in pkg_resources.
The goal of distlib is to provide a library of low-level functions relating to packaging and distribution of Python software, and it does not contain any installers (though it will contain low-level code which could be used by an installer). The distlib code aims to serve as an implementation of the various packaging PEPs, such that if higher level tools use distlib, they should be able to both save writing code (and thereby gain time) as well as achieve better interoperability with other packaging tools. The goal of distlib is not to be a complete packaging solution (which packaging tried to be for Python 3.3, but it proved to be too ambitious a goal). Which issue are you referring to, which you were told was addressed by pkg_resources? From the section starting "Here is what I need", I couldn't see how pkg_resources could fulfil those needs by itself.
Here is what I need: [snip] I can't completely see how I would do this using what is described in the distlib documentation.
What you need is an installer, and distlib doesn't contain functionality to do installation. I won't rehash the various discussions around the needs of Linux distro packagers, except to say that the PEPs have taken into account the needs of distro packagers and the ability to map various parts of a distribution to various target directories in a distro-specific manner. Regards, Vinay Sajip
participants (2)
-
Stanley A. Klein -
Vinay Sajip