Tarek, Martin,
Here's my example of a PKG-INFO (Metadata) file.
It is cut down. I'm only using it in-house. However it
demonstrates something important that could be useful
outside, and that is using a source_repository option.
This file has enough information to do a complete
in-house install of the application. Here's the file:
--PKG_INFO-----------------------------------------------------------
Name: Print Processor
Platform: Windows
Description: Captures standard printer output
and reformats for GDI printers.
Author: David Lyon
Source_repository: hg://V:\Software\HG-Repository\PrintProcessor
--------------------------------------------------------------------
Here is how the complete application install takes place:
* - The 'Name' tag is read. It is used as the 'application'
name.
* A directory in "Program Files" is created with that name.
On Linux, that might be "/usr/local/.." or somewhere else.
What we end up with is a directory such as :
'\Program Files\Print Processor'
* If it was applied to packages, then the directory that
would be created would be:
'\PythonX.Y\lib\site-packages\Print Processor'
* A Mercurial checkout is performed to that directory
* The directory is checked for a setup.cfg file. If that
is found, then further infomation such as desktop/program
file shortcuts can be determined.
* The PKG_INFO file can be used as some sort of record
that the application has been installed.
Anyway, that's just how I'm doing it in-house. We have many
tiny applications to control different sorts of unique
machines, interfaces and whatever, and PKG_INFO files
combined with SCM make it really easy to distribute
applications and keep them up to date on the production
machines.
So really, in a way, PKG_INFO files could be the way
to do lot's more. We just need to be able to mention
the name of the source-repository in them and after
that go from there...
David
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig