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

Re: .py suffixed scripts to /usr/bin/

On Fri, 01 Nov 2013, Paul Wise wrote:
> > So the question is -- is there any other possible resolution I do not
> > see here besides just keeping .py suffixes and providing a lintian
> > override?

> The implementation language is irrelevant to users and thus should not
> be in the names of things in $PATH. We don't suffix binaries compiled
> from C with .c or shell scripts with .sh and python should be no
> different.

concur in general and that is why I am also suggesting such changes
upstream usually.

> The free version is command-line incompatible with the non-free version.

> This leads me to suggest you get upstream to switch to using a suffix
> like -free, -new, -fnme (free NME), -mnet (mne-tools) or prefix like f
> (free). It solves both problems and is really what upstream should
> have been doing from the beginning since .py is hardly the appropriate
> differentiator between the non-free and free versions of the commands.

yeah... upstream was already conscious enough to use a unique prefix
(mne-) and if e.g. it was a pymne project/module, it would have been
logical to just use pymne- prefix.  Since it is call mne-python, having
such a prefix would be way too ugly.

Policy's stand on removing suffixes could also be treated as "they are
irrelevant", and as such it would not matter either suffix is "-new" or
"-py" or ".py" really.

in any case -- upstream seems have liked a 'gateway script' solution:

Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate,     Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

Reply to: