[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

CLI recommendations for version-specific /usr/bin scripts



I'd like to revive the discussion on best practices for installing Python
applications which are version-dependent.  If we can come up with some general
guidelines we can mostly agree on, I'll update the AppStyleGuide wiki page.

Of course, most Python applications which expose a cli don't need to expose
different /usr/bin scripts based on the Python version.  They run on Python 2
or Python 3 and don't care about the minor version number.  So we just install
them as /usr/bin/whatever with a #! of /usr/bin/python or /usr/bin/python3.
Happy happy, joy joy.

Some cli's do care though, e.g. nose.  In those cases, I think common practice
seems to be the following:

 * Ensure that the script can be invoked via -m flag.  Thus

   $python -m myscript

   will always work and do the right thing, when invoked with whatever $python
   you care about (e.g. python2.7 or python3, or python3.3).

 * Expose /usr/bin/foo with a shebang line of #!/usr/bin/python

 * Expose /usr/bin/foo-3 with a shebang line of #!/usr/bin/python3

   - Question: dash or no dash in the script name?  I think we've seen both
     and I don't have a strong opinion, although when the script itself has a
     version number embedded in it, it pretty much has to have a dash between
     that and the Python version.  E.g. /usr/bin/nose2-3.3

 * If the minor version number matters, include a /usr/bin/foo-X.Y with a
   shebang line /usr/bin/pythonX.Y.

   - Question: we don't seem to be entirely consistent about this.  Sometimes
     the shebang line for /usr/bin/foo-X.Y is /usr/bin/pythonX (where X can be
     the empty string for Python 2).

   - Question should /usr/bin/foo-X.Y ever be a symlink to /usr/bin/foo-X?

Those seem to be the rules we're following.  I'm not entirely sure whether
pybuild and friends helps with any of this or stays agnostic.

Am I missing anything?  Can anybody improve on those rules above?  Should we
just adopt them as our standard recommendation (not requirement)?

Cheers,
-Barry

Attachment: signature.asc
Description: PGP signature


Reply to: