[Reproducible-builds] Bug#796196: strip .py suffix from diffoscope within sources repo as well)

[Mattia Rizzolo]

On Thu, Aug 20, 2015 at 07:59:50AM -0400, Yaroslav Halchenko wrote:
> 
> On Thu, 20 Aug 2015, Mattia Rizzolo wrote:
> > > ignore the patch I have submitted (done in a rush, incorrect). But what
> > > about the idea in general?
> 
> > Umh, but why?
> 
> > Shipped package does not have .py.
> 
> > Also, why should we move the script to an another directory? (and then we would
> > need to set PYTHONPATH to be able to do anything…)
> 
> > Can you elaborate on your rationale?
> 
> Sure!
> 
> 1. debian policy on "not having suffix" is not really Debian-specific --
> it is a general recommendation.  In your case diffoscope as utility
> could later be rewritten in some other language etc, which would then
> reflect itself in changing the suffix

That thing relates to the installed binary, and indeed we do not have a suffix
in the /usr/bin/diffoscope file name.

The git repository is something for the development, and the development of
diffoscope depends on the current implementation.

> 2. There is now a dichotomy between how diffoscope should be executed as
> installed from debian package (without suffix) and then if someone
> installs it using setup.py (with the suffix) or just reading your
> documentation (e.g. README)

This to my experience is normal development. stuff in a VCS tends to be a bit
different than installed one.
The README tells about how to use it out of the vcs clone.

> I do appreciate though the fact that with such a change and relocation
> setting of PYTHONPATH is necessary if someone wants to invoke diffoscope
> without e.g. 'python setup.py develop' (ideally within a virtualenv).
> Within fail2ban we even made some ugly workaround for such invocations,
> e.g.
> 
> if os.path.exists("diffoscope/__init__.py"):
>     sys.path.insert(0, ".")
> 
> so someone could invoke directly within source code-base.

This is currently really possible and easy to do, just `./diffoscope.py ...`.

> Alternative to all of the above could be moving that script entirely
> under diffoscope/ module codebase and just establishing entry points with
> setuptools' setup() call.  E.g. how we do in e.g. datalad
> 
> https://github.com/datalad/datalad/blob/master/setup.py#L30
> 
> which would then allow you to craft a test to verify functionality of the code
> in the script.

The current structure seems really sensible and sane to me, while I wouldn't
understand having the program entry point inside the module.

> Anyways -- decision is yours to make ;)

To me your proposals makes really little sense.  But let's wait for the main
developer to show up :)

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540         .''`.
more about me:  http://mapreri.org                                 : :'  :
Launchpad user: https://launchpad.net/~mapreri                     `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia     `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150822/4c1e29f7/attachment.sig>