[Patches] [ python-Patches-415226 ] new base class for binary packaging

[noreply@sourceforge.net]

Patches item #415226, was opened at 2001-04-10 19:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Alexander (mwa)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: new base class for binary packaging

Initial Comment:
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 PEP241 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.

----------------------------------------------------------------------

Comment By: Mark Alexander (mwa)
Date: 2001-10-02 21:10

Message:
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.

----------------------------------------------------------------------

Comment By: david arnold (dja)
Date: 2001-09-20 09:08

Message:
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?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-06-07 05:33

Message:
Logged In: YES 
user_id=21627

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


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470