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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4