Andrew Straw wrote:
Gerry Reno wrote:
Andrew Straw wrote:
I saw your patch, but that wasn't what I meant. Disabling
--single-version-externally-managed has to be optional, and the argument
must continue to be used by default. Simply removing the call will
create a regression for namespace packages. Thus, the
--single-version-externally-managed should only be removed when someone
explicitly asks for it to be removed (because they presumably know what
they're doing or are at least aware it may have negative consequences).
Hence my suggestion to look at how the --ignore-install-requires works
as an example of how to pass an option via the distuils infrastructure.
I'll look at --ignore-install-requires and send another patch.
OK, great.
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.
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.
Maybe we can get some overall guidance here from Tarek who has been
coordinating a lot of these types of things.
Regards,
Gerry
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
