*.py packaging, again

[Patryk Zawadzki]

On Thu, Jul 14, 2011 at 1:19 PM, Jeff Johnson <n3npq at mac.com> wrote:
> This is essentially a "push" strategy, where python compilation
> is forced to undertake package management.
>
> The design problem is that compilation is per-file, while
> registered packages are containers of files. You will
> end up with a package-per-file, and/or some extension
> to a package container to attach compiled files.

I was thinking more like "one package per egg" for packages installed
but "attach files to an existing package" for newly compiled files
that come from known packages. What I am after is rpm being able to
answe "what package does this file belong to" and "what files do I
remove when uninstalling this package".

> You also need to decide whether all compilations are on
> the build system or after installation: there are different
> implementations.

I'd vote for "on install" or "on demand" (think three versions of
python sharing the same python code but each using only a fraction of
installed packages).

-- 
Patryk Zawadzki
I solve problems.