Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8615 > unrolled thread

Best practice for adding python3 version to existing module with helper programs?

Back to article view | Back to linux.debian.maint.python

Contents

  Best practice for adding python3 version to existing module with  helper programs? Neil Muller <drnlmuller+python@gmail.com> - 2016-06-24 00:50 +0200
    Re: Best practice for adding python3 version to existing module with helper programs? Clint Byrum <spamaps@debian.org> - 2016-06-24 01:30 +0200
    Re: Best practice for adding python3 version to existing module with helper programs? Ben Finney <ben+debian@benfinney.id.au> - 2016-06-24 07:40 +0200
      Re: Best practice for adding python3 version to existing module  with helper programs? Barry Warsaw <barry@debian.org> - 2016-06-24 15:40 +0200

#8615 — Best practice for adding python3 version to existing module with helper programs?

I'm working on packaging the latest version of sqlobject, which adds
supprt for python 3, and I'm unsure of how best to handle the helper
applications that ship as part of the package. The helper applications
will work with both python2 and python3, so it's not clear to me how
to apply the advice given in [1], and I'd ideally want the helper
programs available regardless of which version of the module is
installed.

Looking at some other packages in the archive, there seem to be
several approaches used to solve similar problems

a) Bundle the application in both python2 and python3 version and use
alternatives to manage the version (docutils and sphinx, for example,
although in those cases the programs are used fairly extensively as
applications)

b) Install multiple copies with different names (foo and foo-py3 and
similar ideas)

c) Replace the helper with a combination shell / python script
(django-admin for example [2]), which is cute.

Is there any consensus on which approach is best? Any advice on the
pitfalls or benefits of the various approachs? Other tricks I've
missed?

Thanks

[1] https://wiki.debian.org/Python/LibraryStyleGuide

[2] https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/tree/debian/django-admin

-- 
Neil Muller

[toc] | [next] | [standalone]

#8616 — Re: Best practice for adding python3 version to existing module with helper programs?

Excerpts from Neil Muller's message of 2016-06-24 00:26:25 +0200:
> I'm working on packaging the latest version of sqlobject, which adds
> supprt for python 3, and I'm unsure of how best to handle the helper
> applications that ship as part of the package. The helper applications
> will work with both python2 and python3, so it's not clear to me how
> to apply the advice given in [1], and I'd ideally want the helper
> programs available regardless of which version of the module is
> installed.
> 
> Looking at some other packages in the archive, there seem to be
> several approaches used to solve similar problems
> 
> a) Bundle the application in both python2 and python3 version and use
> alternatives to manage the version (docutils and sphinx, for example,
> although in those cases the programs are used fairly extensively as
> applications)

This seems like the most reasonable method, and the one I'd expect as a
user.

[toc] | [prev] | [next] | [standalone]

#8617 — Re: Best practice for adding python3 version to existing module with helper programs?

Neil Muller <drnlmuller+python@gmail.com> writes:

> I'm working on packaging the latest version of sqlobject, which adds
> supprt for python 3, and I'm unsure of how best to handle the helper
> applications that ship as part of the package. The helper applications
> will work with both python2 and python3, so it's not clear to me how
> to apply the advice given in [1], and I'd ideally want the helper
> programs available regardless of which version of the module is
> installed.

What is the purpose of the helper applications? Is there a significant
use case for “I want specifically the Python 2 version of this
application”?

If not, I would advise making only the Python 3 applications available,
in a separate binary package (and put it it “Section: database”) which
describes the purpose without mentioning Python versions.

-- 
 \             “Roll dice!” “Why?” “Shut up! I don't need your fucking |
  `\     *input*, I need you to roll dice!” —Luke Crane, demonstrating |
_o__)                       his refined approach to play testing, 2009 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8618 — Re: Best practice for adding python3 version to existing module with helper programs?

On Jun 24, 2016, at 03:30 PM, Ben Finney wrote:

>Neil Muller <drnlmuller+python@gmail.com> writes:
>
>> I'm working on packaging the latest version of sqlobject, which adds
>> supprt for python 3, and I'm unsure of how best to handle the helper
>> applications that ship as part of the package. The helper applications
>> will work with both python2 and python3, so it's not clear to me how
>> to apply the advice given in [1], and I'd ideally want the helper
>> programs available regardless of which version of the module is
>> installed.  
>
>What is the purpose of the helper applications? Is there a significant
>use case for “I want specifically the Python 2 version of this
>application”?
>
>If not, I would advise making only the Python 3 applications available,
>in a separate binary package (and put it it “Section: database”) which
>describes the purpose without mentioning Python versions.

I concur with Ben.  If the end user won't care whether Python 2 or 3 is used
and the helper works the same regardless of which Python invokes it, please
just ship the Python 3 version.  It should go in a separate binary package.

Cheers,
-Barry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web