python: pkg control

python: pkg control

Post by David Le » Sat, 24 Jun 2006 23:42:56



For a simple package, "pkgadd" puts files into the system, and "pkgrm"
removes those files.

But the "python" interpreter generates bytecode files (filename patterns
*.pyc and *.pyo) alongside the normal *.py files.  So these files get left
behind when "pkgrm" is run, which is somewhat untidy and asymmetric.

Are there conventions in the "pkg" mechanism for handling these extra
*.pyc and *.pyo files?  There are probably (at least) two issues:

1. pkgrm: how to remove these files that have magically appeared?

2. pkgadd: how to manage and acknowledge their automatic appearance (or
perhaps force their creation for an install-time run of python, so that
their appearance will not have been magic).

If there are established conventions that I can use, then I won't be
re-inventing the wheel.

--

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :

 
 
 

python: pkg control

Post by Philip Morte » Sun, 25 Jun 2006 00:03:38



> For a simple package, "pkgadd" puts files into the system, and "pkgrm"
> removes those files.

> But the "python" interpreter generates bytecode files (filename patterns
> *.pyc and *.pyo) alongside the normal *.py files.  So these files get left
> behind when "pkgrm" is run, which is somewhat untidy and asymmetric.

> Are there conventions in the "pkg" mechanism for handling these extra
> *.pyc and *.pyo files?  There are probably (at least) two issues:

> 1. pkgrm: how to remove these files that have magically appeared?

> 2. pkgadd: how to manage and acknowledge their automatic appearance (or
> perhaps force their creation for an install-time run of python, so that
> their appearance will not have been magic).

> If there are established conventions that I can use, then I won't be
> re-inventing the wheel.

You could write a preremove script that deletes the files before pkgrm
does the removal of the predefined files and directories, or after they
have been created, you could use installf to add them to the package so
that pkgrm knows to remove them.

Philip Morten

 
 
 

python: pkg control

Post by Casper H.S. Di » Sun, 25 Jun 2006 00:13:10



>For a simple package, "pkgadd" puts files into the system, and "pkgrm"
>removes those files.
>But the "python" interpreter generates bytecode files (filename patterns
>*.pyc and *.pyo) alongside the normal *.py files.  So these files get left
>behind when "pkgrm" is run, which is somewhat untidy and asymmetric.
>Are there conventions in the "pkg" mechanism for handling these extra
>*.pyc and *.pyo files?  There are probably (at least) two issues:

Generally such byte compiled files are either stored in the package
or removed in the pre-remove script.

Quote:>1. pkgrm: how to remove these files that have magically appeared?

There are two options:

        - not making them magically appear and just ship them as part
          of the package

        - use a preremove script which removes the files before removing
          the rest of the package.

Quote:>2. pkgadd: how to manage and acknowledge their automatic appearance (or
>perhaps force their creation for an install-time run of python, so that
>their appearance will not have been magic).

Ship 'em, use installf or just preremove them.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

python: pkg control

Post by Albert Chi » Sun, 25 Jun 2006 08:33:22



> But the "python" interpreter generates bytecode files (filename patterns
> *.pyc and *.pyo) alongside the normal *.py files.  So these files get left
> behind when "pkgrm" is run, which is somewhat untidy and asymmetric.

> Are there conventions in the "pkg" mechanism for handling these extra
> *.pyc and *.pyo files?

> If there are established conventions that I can use, then I won't be
> re-inventing the wheel.

Look at file type "v" in prototype(4).

--
albert chin

 
 
 

python: pkg control

Post by David Le » Tue, 27 Jun 2006 19:20:23




> >For a simple package, "pkgadd" puts files into the system, and "pkgrm"
> >removes those files.

> >But the "python" interpreter generates bytecode files (filename patterns
> >*.pyc and *.pyo) alongside the normal *.py files.  So these files get left
> >behind when "pkgrm" is run, which is somewhat untidy and asymmetric.

> >Are there conventions in the "pkg" mechanism for handling these extra
> >*.pyc and *.pyo files?  There are probably (at least) two issues:

> Generally such byte compiled files are either stored in the package
> or removed in the pre-remove script.
> [...]

OK.  Thanks.  So a general convention is that they are specifically
created relatively early in the overall package creation-and-shipping
process, to be stored into the package at package-creation time.

(My query was primarily the managerial aspect of the best practice to
adopt.)

We're using automake, autoconf etc.  I now see that automake has a
"_PYTHON" primary, which seems to have been added to automake at around
the time that the "Goat Book" was being published.  So "_PYTHON" didn't
reach the Goat Book (so it didn't come onto our radar).

A quick test suggests that the "_PYTHON" primary arranges for the "*.pyc"
and "*.pyo" files to be created automatically at "make install" time.

Our own code ("heartbeat" aka "Linux-HA") uses "make install" to create
the pkg (and its manifest file list).  So it looks as though switching
from "_SCRIPTS" to "_PYTHON" in our automake descriptions could be a
clean and consistent way for us to tackle this.  (And non-Solaris
platforms should also gain consistency from this.)

Many thanks to Casper and to others who have replied to this thread.

--

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :

 
 
 

1. Fwd: cvs commit: ports/java Makefile ports/java/jboss2 Makefile distinfo pkg-comment pkg-deinstall pkg-descr pkg-install pkg-plist

FYI.

Ernst

----------  Forwarded Message  ----------

Subject: cvs commit: ports/java Makefile ports/java/jboss2 Makefile        
distinfo pkg-comment pkg-deinstall pkg-descr pkg-install pkg-plist
Date: Fri, 26 Apr 2002 14:54:16 -0700 (PDT)


znerd       2002/04/26 14:54:16 PDT

  Modified files:
    java                 Makefile
  Added files:
    java/jboss2          Makefile distinfo pkg-comment
                         pkg-deinstall pkg-descr pkg-install
                         pkg-plist
  Log:
  New port jboss2.

  The jboss2ctl program does not work at this stage. I chose
  to commit this port anyway because it has been lying around
  for too long. Once it is in the ports tree, the improved
  interest may trigger somebody else to fix the problem.

  JBoss can be started using the supplied shell script anyway,
  so it is still useful.

  This is not the JBoss port submitted by Jesse Gallup in PR
  35853, but one based on the www/orion port.

  PR:     35853

  Revision  Changes    Path
  1.49      +1 -0      ports/java/Makefile
  1.1       +160 -0    ports/java/jboss2/Makefile (new)
  1.1       +4 -0      ports/java/jboss2/distinfo (new)
  1.1       +1 -0      ports/java/jboss2/pkg-comment (new)
  1.1       +45 -0     ports/java/jboss2/pkg-deinstall (new)
  1.1       +24 -0     ports/java/jboss2/pkg-descr (new)
  1.1       +46 -0     ports/java/jboss2/pkg-install (new)
  1.1       +1324 -0   ports/java/jboss2/pkg-plist (new)

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


with "unsubscribe freebsd-java" in the body of the message

2. Highlighting in C-shell

3. RedHat control panel tools broken (Python problem?)

4. strange samba problem

5. Two issues; pkg use and pkg format

6. HP700RX - Linux X-Terminal???

7. How do I build a pkg that will remove ALL files associated with the pkg

8. Looking for Automated scripts for nfswatch 4.0

9. pkgadd <pkg> AFTER applying a patch affecting <pkg>

10. Advice sought: global zone pkgs vs. local zone pkgs

11. pkg-get, pkg

12. Source control/Version control wanted

13. minicom's scrollback problem, what about Control-S, Control-Q?