[Debian-med-packaging] Bug#936395: Could you imagine to convert dicompyler to Python3? [Was: dicompyler is marked for autoremoval from testing]

[Andreas Tille]

Hi Vojtech,

On Sun, Sep 15, 2019 at 11:15:23AM +0200, Vojtech Kulvait wrote:
> Hi Andreas,
> I was just looking to check the state of the upstream project. The upstream
> developer pushed into the github version 5.0.0 of dicompyler. It uses
> Python3 and the main window shows in buster just after installing some
> standard packages from repositories, namely python3-pydicom and
> python-wxgtk4.0.

Thanks a lot for checking this out.
 
> Only caveat is that upstream developer separated the project to the two
> github repositories, dicompyler for UI and dicompyler-core with the scripts
> essential for computation. I propose to integrate them both to one Debian
> package, separation makes not too much sense here for Debian use case.

While it sometimes is not clear from one users perspective other users
(who might follow the philosophy of upstream) might expect the same
separation.  Besides this its technically easier to follow separate
upstream repositories.  Guess these might run out of sync with version
numbers (for whatever reason) and you need to watch two sources which is
a nightmare from a maintenance point of view (at least I would not do
this personally with my 20 years packaging experience).

Moreover there is actually a package python3-pydicom.  Its based on
    https://pydicom.github.io
and maintained in Debian at
    https://salsa.debian.org/neurodebian-team/pydicom
Could you say something about the relation of these two pydicom
implementations?  If they are different the author should be informed
about a name clash.

> There are some problems, namely that the developer is using the feature
> removed from matplotlib current release, that is packaged already for
> buster,
> https://stackoverflow.com/questions/49160142/how-should-cntr-should-be-imported-on-matplotlib-lts-2-2-0
> so
> this is something to have a look at when porting, probably contours will
> not be visualized since it needs to dig more into the program logic, or we
> can file upstream bugreport.

Ahhh, making use of removed features is a nuisance.  Better file a bug
report rather sooner than later.
 
> There seems to be other problems, maybe with version incompatibility,  that
> might need attention so I was not able to visualize anything due to the
> following errors:
>   File "/usr/lib/python3/dist-packages/pydicom/dataset.py", line 536, in
> __getattr__
>     return super(Dataset, self).__getattribute__(name)
> AttributeError: 'Dataset' object has no attribute 'TransferSyntaxUID'
> File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2338, in
> _check_size
>     raise ValueError("Size must be a tuple")
> ValueError: Size must be a tuple
> 
> So my verdict is that the current github master version can be used to port
> it in Debian system after hopefully small changes. How much time do I have
> to fix the bugs?
 
Well, we are in the beginning of the Debian 11 release cycle.  So we are
pretty safe if we manage until summer next year.  But I'm personally a
friend of doing things rather earlier than later since the issues above
sound a bit complex.

Thanks a lot in any case for your intention to work on this.  That is
really appreciated.  Please always keep the bug e-mail address in CC to
keep other readers informed.

Kind regards

        Andreas. 

-- 
http://fam-tille.de