Re: [Fink-devel] Python dependency question….

[Alexander H. <ale...@gm...>]

On 10/21/12 10:40 AM, Scott Hannahs wrote:
> I have a package (duplicity) that for some reason did not get moved to the 10.8 tree.  

The reason would be that you didn't ask to have it done. :-)  We haven't
been moving things automatically, and so packages that nothing else
depend on can get left behind.

I have updated the package and it builds on Mac OS X 10.8, 10.6 and 10.5.
> 
> The package is dependent on python.  The minimum requirement is python 2.4 and has been tested up to python 2.7.  What is the best route
> 	A. Require python 2.7 in the dependencies since it is available in all systems as a build
> 	B. Let the user chose by creating a duplicity-py24, duplicity-py25, duplicity-py26 and duplicity-py27
> 	C. Other, is there a method for creating a dependence on "python (>= 2.4)" ??
> 
> I have created the updated version based on A but that forces a large install for many users.  Option B seems more user interaction than is necessary for such a package.  C would be fine but I haven't seen that used in any other package and not sure it is legal.  Also there is a dependence on boto-py27 which is explicit.  My current depends are:
> # Dependencies.
> BuildDepends: librsync (>= 0.9.7-1002), fink (>= 0.24.12-1)
> Depends: python27, librsync-shlibs (>= 0.9.7-1002), ncftp, lftp, boto-py27
> 
> There are cases where a user would want python 2.6 or greater since it allows multiprocessing some of the data transfers but is there a better way to make the package use already installed or system versions of python?
> 
> Secondly, the fink web site seems to be down so where do I submit packages?

The sourceforge tracker isn't down, fortunately.  Go to
http://sourceforge.net/projects/fink/ and there's a Tracker item on the
menu bar.

> 
> Thanks,
> Scott
> 
> 

This is an package focusing on a user executable, yes?

Some maintainers like to do variants for multiple Python versions in
such cases and then use update-alternatives to select the executable
(your B).  Pros: users don't have to install an additional python.
Cons: harder to maintain

For maintenance purposes, it's usually easier just to pick a single
Python version (A).  Pros: simple to maintain.  Cons: users gripe about
having to install python27 if they have some other version installed.

A dependence on "python" isn't that useful, since that's a convenience
package pointing by default to python27.

Something like option (C) isn't allowable unless a package just runs
Python scripts.  If there is any linkage to a libpython then one can't
swap in a different version.

Use of the system's Python would require the entire dependency chain of
Python modules also to be built against the system's Python.  If a
package doesn't use any other Python modules, but instead just needs a
Python to run scripts, that's different.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/