Re: .py endings or no .py endings for scientific packages
Hi,
sorry for my silence - this week I'm busy with real life mostly.
On Sun, Jun 17, 2018 at 01:24:10PM +0900, Charles Plessy wrote:
> > How about a paragraph in the Debian Med policy? Maybe like
> > "Many packages created for scientific purposes have executables with
> > language-characteristic suffices like .pl or .py. This is not appropriate
> > for public interfaces of a software that should be implementation-agnostic.
> > It is a Debian Policy requirement to correct this for packages uploaded
> > to the main distribution. Such distribution-specific changes however
> > are discouraging the exchange of protocols between scientists. The
> > package maintainer is encouraged to work with upstream to correct
> > the naming of these files, but may decide to locally only override
> > the lintian warning for the time upstream needs to distribute a corrected
> > version of their software."
>
> Good idea. And the Lintian overrides can link to the Debian Med policy.
>
> Regarding the text above, I would go even further and not suggest to
> contact upstream with a rename requests,
Please contact upstream in any case. I think there are always good
reasons to contact and the reasons are summarised in our Wiki[1]. I do
not think that beeing a scientist is an excuse to ignore good hints from
IT experts. We can not do much about it but I would even consider it
mean if we know good reasons for better names and hide this from
upstream.
> unless the script is a "public
> interface", which is almost never the case in our packages.
You can never know how things develop and its better to change this kind
of things sooner rather than later. It might be that the authors start
writing some new software and might apply our hints there.
BTW, we could also consider symlinks to a binary without extension.
What we can do in any case is using /usr/lib/debian-med/bin for
original names (as we do for name space conflicts anyway).
Kind regards
Andreas.
[1] https://wiki.debian.org/UpstreamGuide#Language_extensions_in_scripts
--
http://fam-tille.de
Reply to: