Re: Any software package for Radiation Oncology Contouring?
Hi Andreas,
On Tue, Mar 15, 2011 at 03:21, Andreas Tille <andreas@an3as.eu> wrote:
> thank you very much for your interest in Debian Med. For our project it
> would be a really great addition to also support radiation therapy
> research - so I really hope to get it packaged for Debian soonish. I'm
> personally neither involved nor educated in this field and I hope that
> our experts here on this list will rise their hand and volunteer for
> packaging. If this might not be the case I'll probably try to step in
> and do the packaging work. However, the testing of the resulting
> packages needs to be done by somebody who has a real use for the
> packages.
That is great! I am willing to test the packages, however I am
unfamiliar with the packaging process itself, so it may be better to
leave it to individuals who are more familiar with it.
> So far for the general position - read below for certain details:
>
> I've checked the requirements and as far as I can see all preconditions
> are available in Debian. :-)
That's great. The only issue could be is that we used to have a
dependency on Elixir (present in 0.3, but removed in one of the latest
changesets). That requirement now has become simplejson for Python 2.5
(as Python 2.6 already includes this).
> Regarding "Getting the source": While it is perfectly possible to
> obtain the source from any Version Control System it would be of great
> help if you would release your final code into versioned tarballs.
> So even if we are targetting at your not yet released version 0.4
> it would be good to know that you have released something like
> dicompyler-0.3.tar.gz at your download page[1] (and perhaps previous
> versions) and that we can trust to find dicompyler-0.4.tar.gz on
> this (or some other defined) location.
>
> The rationale behind this is that we always need to provide a source
> tarball in Debian and that it is the easiest way to use the "official"
> upstream tarball. We also have an automatic system which verifies the
> upstream site every day for new updates - it would be a shame if we
> would not have this option.
Not a problem to create a tarball of the source with each release.
> Could you please clarify what in this connection "clone" would mean
> (Niels Bassler is in CC)? Will this code be merged at some point in
> time? What should be our code we should target for Debian inclusion?
> If it is just the distutils build system I do not think it is the best
> idea to have two clones hanging around in different Version Control
> Trees. It is confusing for visitors of these pages and finally more
> work for you to set up different pages with same information. I also do
> not understand the relation of nielsbassler-dicompyler and PyTRiP (which
> is mentioned on the later page).
>
> Is PyTRiP a different project (solving different tasks) than dicompyler
> or it is rather a competing project targeting at the same workflow but
> with different code. I did not found a license at the PyTRiP
> homepage[2] even if there is some link to the source code in TRAC.
Niels created PyTRiP as a different project, but the goals are similar
with regards to visualization. The input files for dicompyler are
basically DICOM / DICOM RT; PyTRiP uses TRiP and VIRTUOS files. There
are some differences as to what libraries are used for visualization,
but eventually we may use these as well in dicompyler (i.e. VTK for 3d
rendering). (Niels, please correct me if I am wrong).
Eventually, we are considering adding support for other file readers
into dicompyler, but as for now the goal for dicompyler is to work
primarily with DICOM data.
Also, dicompyler is a plugin-based project, so if someone prefers a
certain rendering method, they may choose to replace the plugin with
one of their own.
That said, Niels created a personal clone on the dicompyler Google
Code page that has additional functionality added to dicompyler, one
of that being he moved the source files around so that it would be
ready for packaging via distutils. That rearranging has not happened
on the main source tree, but will eventually, if needed to facilitate
packaging. I just suggested it in case it helps to look at the work as
a basis to prepare the main source tree.
Niels may want to also have a Debian package for PyTRiP, but I will
defer that discussion to him.
So to answer your question, we should base the package around the main
source, obviously which will be tarballed at the time of release.
> So we need to clarify first:
>
> 1. What will be the target project for Debian inclusion
> Dicompyler or nielsbassler-dicompyler (in case it is not
> intended to merge both projects again).
dicompyler will be the main target for Debian inclusion. There will be
some merging of the projects at some point, but that will be
determined later once the project becomes more mature.
> 2. If this is decided can you please release source tarballs
> of this project. If the difference in the build system
> between a previous release and the future release is not
> very large we might start the packaging even with an older
> version and just upgrade your upstream code for a final
> release. If the build system is quite different we might
> consider a dicompyler-0.3.99alpha.tar.gz (or whatever version
> to start working on this).
I can provide a tarball now of release 0.3 or the most recent source,
whichever would be more useful. The dependency switch would have
already taken place if I provide a tarball of the most recent source.
> 3. If you personally feel able to take over some packaging
> work under the guidance of the Debian Med team this could
> turn out as a quite fruitful cooperation. It worked quite
> good in the past. Debian packaging is not that hard to
> learn in the end and we will patiently help you doing so.
I would consider this depending on how much work is required. However,
if it is non-trivial, I would like to get some assistance with the
packaging. Honestly, I don't use Debian but do have Ubuntu installed
in a VM, so I can try to get what I can working. We also have another
developer, Roy Keyes (CC'ed on this), who works primarily with Linux,
so he may be interested in lending a hand in this effort.
Thanks for the insight,
Adit
Reply to: