new base class for binary packaging

[mwa]

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:

assignee = 'https://github.com/malemburg'
closed_at = <Date 2002-04-17.19:43:52.000>
created_at = <Date 2001-04-10.19:51:46.000>
labels = ['library']
title = 'new base class for binary packaging'
updated_at = <Date 2002-04-17.19:43:52.000>
user = 'https://bugs.python.org/mwa'

bugs.python.org fields:

activity = <Date 2002-04-17.19:43:52.000>
actor = 'lemburg'
assignee = 'lemburg'
closed = True
closed_date = None
closer = None
components = ['Distutils']
creation = <Date 2001-04-10.19:51:46.000>
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 = []

[mwa]

bdist_packager.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.

[loewis]

Logged In: YES
user_id=21627

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

[dja]

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?

[mwa]

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.