Andrew Straw wrote:
OK, based on your code I added a "bdist_deb" distutils command to
stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:
python -c "import stdeb; excecfile('setup.py')" bdist_deb
See this was my point of why my 'bdist_deb' belonged as a distutils
patch and not in stdeb.
The inherited capabilities, behaviors and invocation style needs to
follow all the other 'bdist' command types.
And that means being able to invoke it the same as say 'bdist_rpm'
like:
python setup.py bdist_deb
or
python setup.py bdist_deb --<std bdist type arg> ...
If we start allowing 'bdist' derivative commands to diverge in their
inherited capabilities, invocation style, and expected behaviors then
chaos will ensue.
This does have the same invocation style -- if you change your setup.py
to import stdeb. Otherwise, it's still the same invocation style -- you
just have to import stdeb outside the setup.py file.
Also, this version of bdist_deb is never going to make it into the
standard library as it depends on stdeb.
So feel free to make a counter proposal, but I'm inclined to think this
is useful to people as-is and has the benefit of working today.
My view is this. The 'bdist' family of commands should be reserved
for pure Distutils implementations not dependent upon setuptools or
stdeb. Putting a command to create the .deb based on my code into
stdeb is fine but that command should not be a 'bdist_xxx' command.
It should be somthing like bstdeb_deb so that a true 'bdist_deb' can
still be developed for Distutils and not be in conflict with some
other 'bdist_deb' out there.
Well, it wouldn't be setting a precedent that importing a module would
extend the functionality of the stdlib's distutils commands -- the
setuptools and distribute projects already do this. For example, the
"sdist" command in setuptools has many differences with that of "sdist"
in plain distutils. The point is that a user can choose not to import
setuptools and thus not get the different behavior.
The case here is that if the stdlib ever grows bdist_deb, that's fine,
but I don't see why that should prevent stdeb from implementing a
bdist_deb command of its own. In this case, I think the issue is even
less relevant, since there is no stdlib "bdist_deb" command. Users would
naturally expect "bdist_deb" to do exactly what stdeb is implementing.
As long as I'm going ahead an implementing the functionality (which I'm
ambivalent about in and of itself for previously stated reasons), I
think it should be named the most obvious name.
My only concern is that namespaces are important and if we end up with
two solution paths that each use the same namespace then this becomes
very confusing for users. Yes, I understand that if you don't import
stdeb in your setup.py then you can use a 'bdist_deb' from Distutils.
At some point, the 'bdist' family of commands should evolve into
OS-specific varieties. And this means that for example, redhat,
fedora, mandriva, or any other rpm-package distro would have their own
'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
institute their own rules/policies onto a generic 'bdist_rpm'. And
the same would hold true for example a 'bdist_ubuntu' command that
would inherit from a 'bdist_deb' command or in general for any
'bdist_DISTRO' command that would inherit from a 'bdist_PACKAGETOOL'
command.
I don't see what's so specific about ubuntu versus debian right now that
there's any reason for a different set of commands for the two.
Therefore, I think this is a red herring w.r.t. the present discussion.
For ubuntu, at the moment at least, that's true. But distros like
redhat are creating their own rules/policies around rpm naming
conventions, build options, etc. and of course they should be able to do
this and I expect other distros will do the same, and these will diverge
more over time even though they will all use the same packaging tool
underneath.
Maybe we can get some overall guidance here from Tarek who has been
coordinating a lot of these types of things.
I think this is a good topic for someone with a long view about where
things are headed here to weigh in on this.
I'm fine with whatever fits in with the longer term goals.
Regards,
Gerry
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
