[Python-Dev] splitting out bdist_*

[Eric Smith]

Stephen J. Turnbull wrote:
> Eric Smith writes:
> 
>  > And I personally use bdist_rpm for my work, which I distribute to a farm 
>  > of servers under my control. So no doubt it's used.
> 
> Sure, but use for internal distribution is very different from to
> problem its being asked to solve now, isn't it?  IIUC, you're
> basically using RPM as an installer for a standalone application,
> where you set policy at both ends, packaging and installation.  This
> may be a group of modules which may have internal interdependencies,
> but very likely the environment doesn't change much.  Pretty much
> anything will do in that kind of situation, and I don't think it would
> matter to you if there are zero, one, or twelve such tools in stdlib,
> as long as there's one you like in PyPI somewhere.

I was just pointing out that bdist_rpm has users, and it's not likely to 
be abandoned. It's certainly true that different users have different 
use cases for it.

It's this lack of understanding of all the use cases that most concerns 
me about this overall effort. How can we know if we succeeded if we 
don't all agree on the state we're trying to get to?

To be concrete, I think distutils should support (among other things):
- entry points for plugins
- entry points as used for producing console and windowed "scripts"
- dependency declarations for other python packages
- dependency declarations for non-python packages

But maybe these goals aren't shared by others, and don't fall into 
anyone else's "make distutils better" concept.

PJE pointed out "A library that targets Python 2.4 and 2.5 and uses 
wsgiref, sqlite, ctypes, or ElementTree, for example, may have different 
dependencies depending on the version it is being installed in." Is that 
something we want to support?

>  > [That .deb tools are necessarily maintained outside of bdist]
>  > proves that [external maintenance] doesn't help given the current
>  > state of affairs. I suspect that if all of this additional
>  > information needed to build a .deb (for example) could be included
>  > as metadata in the python package (using the word "package"
>  > loosely), that it would be. It would make the ultimate packager's
>  > life easier, and it's no real burden for the original author.
> 
> I'm not sure what you mean by "it would be".  Are you referring to
> what I believe to be true, that because Python and Python-based apps
> need to integrate with the rest of the OS, it's quite burdensome for
> module authors to include the necessary information, which is likely
> to vary from packaging tool to packaging tool, and according to policy
> even among packagers using the same tool?  Or do you mean that it
> would be useful, so it would be nice if such information were
> included, and that as you see it the required effort would be small?

I don't see how they differ. It's definitely true that packagers using 
the same tool might want to produce different package layouts and no 
doubt other differences. I don't see why it wouldn't be easy to have 
these differences driven by different policies acting on the same 
metadata, or small amounts of custom (per-packager) metadata.