new base class for binary packaging

[7ac61f6c-5151-46eb-8e08-339a1081e4bd]

BPO	415226
Nosy	@malemburg, @loewis
Files	bdist_packager.py: bdist_packager.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/malemburg' closed_at = created_at = labels = ['library'] title = 'new base class for binary packaging' updated_at = user = 'https://bugs.python.org/mwa' ``` bugs.python.org fields: ```python activity = actor = 'lemburg' assignee = 'lemburg' closed = True closed_date = None closer = None components = ['Distutils'] creation = creator = 'mwa' dependencies = [] files = ['3257'] hgrepos = [] issue_num = 415226 keywords = ['patch'] message_count = 5.0 messages = ['36326', '36327', '36328', '36329', '36330'] nosy_count = 4.0 nosy_names = ['lemburg', 'loewis', 'dja', 'mwa'] pr_nums = [] priority = 'normal' resolution = 'duplicate' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue415226' versions = [] ```

[7ac61f6c-5151-46eb-8e08-339a1081e4bd]

bdistpackager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP-241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring any additional fields. It would be nice if by simply supplying the PEP-241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option.

The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though.

[61337411-43fc-4a9c-b8d5-4060aede66d0]

Logged In: YES user_id=21627

Shouldn't the patch also modify the existing bdist commands to use this as a base class?

[9eb8f6e0-6438-4af0-aba2-fddf7d681a8a]

Logged In: YES user_id=78574

i recently struck a case where i wanted the ability to run a post-install script on Windows (from a bdist_wininst-produced package).

while i agree with what seems to be the basic intention of this patch, wouldn't it be more useful to have the various scripts run by the Python interpreter, rather than Bourne shell (which is extremely seldom available on Windows, MacOS, etc) ?

i went looking for the source of the .exe file embedded in the wininst command, but couldn't find it. does anyone know where it lives?

[7ac61f6c-5151-46eb-8e08-339a1081e4bd]

Logged In: YES user_id=12810

Regarding script code: The preinstall, postinstall, etc. scripts are hooked into the package manager specific subclasses. It's the responsibility of the specific class to "do the right thing". For *NIX package managers, this is usually script code, although changing the help text to be more informative isn't a problem.

More specifically, using python scripts under pkgtool and sdux would fail. Install scripts are not executed, they're sourced (in some wierd fashion I've yet to identify). Theoretically, using a shell script to find the python interpreter by querying the package manager and calling it with either -i or a runtime created script should work fine.

This is intended as a class for instantiating new bdist commands with full support for PEP-241. Current bdist commands do their own thing, and they do it very differently. I'd rather see this put in as a migration path than shut down bdist commands that function just fine on their own. Eventual adoption of a standard abstract base would mean that module authors could provide all metadata in a standard format, and distutils would be able to create binary packages for systems the author doesn't have access to.

This works for Solaris pkgtool and HP-UX SDUX. All three patches can be included with ZERO side effects on any other aspect of Distutils. I'm really kind of curious why they're not integrated yet so other's can try them out.

[malemburg]

Logged In: YES user_id=38388

Replaced by 531901.