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 `-
signature.asc
Description: Digital signature
