Re: .py endings or no .py endings for scientific packages
On 15/06/18 13:58, Charles Plessy wrote:
> Le Fri, Jun 15, 2018 at 01:48:17PM +0200, Steffen Möller a écrit :
>>
>> I just updated cnvkit locally and found Michael's patch "Remove .py
>> extensions as per Debian policy". I personally came to the conclusion
>> that differences to upstream in the naming of binaries is detrimental
>> for the acceptance of our distribution in the scientific community.
>> Just, nobody wants to risk to have their larger scripts/workflows fail
>> at some point because Debian does its own thing.
>>
>> For cnvkit it seems particular unfortunate since conda already
>> distributes it. And they with some good confidence do not care about .py
>> suffices. So incompatibilities with the community at larger would be
>> guaranteed. If we truly care about the removal of .py suffices then we
>> should attempt to convince upstream about it.
>
> Hi Steffen and everybody,
>
> I think that deviating from upstream file names is a disservice to our
> users. In my experience, people who push the hardest for the renaming
> are people who have no stakes in the package itself. I failed to get
> the Policy changed on that topic, but my personal opinion would be to
> disregard it until the technical committee would armtwist us to hurt our
> users (or open the way to a Policy change).
Hi, Charles.
I have sympathy with Steffen's point of view about removing .py suffixes
because, in the Linux world, we are used to source files having suffixes
and executables not. However, portability across all supported platforms
requires the file-type to be recognised from the suffix on systems that
don't use Linux '#!' and other magic numbers to recognise file types.
I don't think it's helpful to talk about 'arm-twisting' or 'convincing'
upstream developers to drop .py suffixes when an important objective of
many scientific pipelines is to avoid platform dependencies. Acceptance
of Debian-Med by the wider 'scientific community' depends on a flexible
approach to cross-platform compatibility issues, in my opinion.
I'm working on Bio-Linux 9, based on Ubuntu-MATE 18.04 LTS + Debian-Med,
but I will also include "Bioconda" because I want to make a genuinely
useful bioinformatics platform instantly available to biologists on a
USB stick. In my experience, the greatest obstacle to acceptance of
Linux by biologists is its incompatibility with Windows and Mac OS.
> The disservice is not hypothethical. I advertised a Debian package to a
> colleague, and he came back to me saying that the scripts made by
> another colleague did not work... Indeed the other colleague was not
> using Debian, and therefore was compatible with Upstream and the rest of
> the world...
I use Debian-Med packages every day for my scientific work and I really
appreciate the hard work that the Debian-Med team have done to make this
software available via the Debian Sid repositories that Ubuntu is based
on, but I dislike the dogma about issues like removing .py suffixes and
the 'technical committee' dictating to me or you how we should work...
Bye,
Tony.
--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. +44(0)19755 63548 http://minke-informatics.co.uk
mob. +44(0)7985 078324 mailto:tony.travis@minke-informatics.co.uk
Reply to: