Re: .py suffixed scripts to /usr/bin/
On Thu, 31 Oct 2013, Jonathan Dowland wrote:
> On Thu, Oct 31, 2013 at 03:24:02PM -0400, Yaroslav Halchenko wrote:
> > > Urgh. How about installing the .py to a private directory (under
> > > /usr/share say?) and creating non-suffixed symlinks in /usr/bin.
> > how that would help in case of a conflict with original MNE's binaries
> > becoming available/conflicting?
> Unless the original puts the .py files in the same /usr/share directory,
> or starts shipping suffix-less binaries, it won't conflict.
> > yeap -- I would need to patch their scripts since internally they use
> > each other... imho could introduce more pain than gain
> Ouch indeed. Can you convince upstream to strip the .py suffix for a
> later version?
the hurdle again is that those then would/could conflict with the names
of the now non-free MNE toolkit, which ships files with the same names.
This Python toolkit pretty much tries to mimic and interface in few
spots the original non-free MNE toolkit, thus they chose to have the
same filenames, just with .py suffix to discriminate from the original
MNE. Adding e.g. _py to the filename would have had no more advantage
over having .py suffixes.
So regarding first suggestion with symlinks without suffixes under
/usr/bin/ -- they might then conflict with that non-free MNE
toolkit filenames happen someone had them installed "manually" under
/usr/bin or may be latter happen the sky comes closer to us and MNE
itself becomes FOSS.
--
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: