>>>> 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. > 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. > Maybe we can get some overall guidance here from Tarek who has been > coordinating a lot of these types of things. Sure. CCed. -Andrew _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig