pynetdicom_legacy
pynetdicom_legacy copied to clipboard
patmun
pynetdicom vs pynetdicom3
hey @patmun ! I am a software engineer at Stanford, and found your repo and what appears to be a branch in python 3 (I posted a similar issue here https://github.com/scaramallion/pynetdicom3/issues/55) Basically I'm looking to implement and help contribute to a python based dicom server, and I'm wondering how these two projects are related (or not) and which would be best to start with. Thanks for the feedback!
Hi @vsoch! Your right pynetdicom3 is a fork of pynetdicom by @scaramallion which brings python3 compability plus many improvements in terms in the code, documentation, unit tests, etc. In terms of fonctionality, it is pretty much the same. I think @scaramallion did a wonderful job. I don't know what her or his plans are regarding to this fork, but I would really like to merge it with pynetdicom, so as to remove confusion. Although I'm the original creator of this project, I have not been the most active since a good while and your contribution would be highly appreciated as long as I'm concerned. I suggest you get familiar with the DICOM standard, if you're not already, and with the global structure of the project (start with @scaramallion's version: it is much better documented and cleaner than mine).
hey @patmun ! I've been doing just that, and so far it's looking really good. I think it would be great to get these projects merged back into one collaborative effort, so then pynetdicom has support for 2 and 3. Let me take a look at the differences and see the best way to go about this - I posted on @scaramellion issue board but haven't heard back yet.
so it seems like the pynetdicom3 is more developed, in terms of having more organization of the classes, tests and examples, and of course support for python 3. Differences would be with regard to docs and pynetdicom3 uses pydicom directly, whereas you have wrapper functions for it in the dicom module. Have the two of you talked about perhaps merging pynetdicom3 into what is now pynetdicom? @patmun - do you see any functionality in the current pynetdicom that is not addressed by pynetdicom3? If it comes down to changing the module structure/naming that might break current user's implementations, then the fix for that would be making it clear that they would need to install a particular version. What we would want is the pynetdicom on pypi to be further developed, and have support for both 2 and 3! Here are my suggestions for moving forward:
Initial Merge and Things to Check
- identify functions/features that pynetdicom has and pynetdicom3 does not. They should be added via PR to pynetdicom3 (if @scaramallion is active and wanting to work on it). If not, we can do a fork.
- Identify any possible breaking of things due to differences in naming, etc. Minimally, anyone who uses it with dependency should have clear instructions of how to update (or install the older version).
- Once we have a pynetdicom3 that we like, we should have it PRed to change the current pynetdicom.
- I'd also like to check the status of pydicom. It looks like it's being actively maintained, which makes me happy :) It would be the main dependency for pynetdicom.
The reason for having one central, stronger project is so that we can come together and work on it together. There is really bad need for simple python-based tools that use different components of dicom, and a more centralized effort will be great for the open source community.
Updates
What I'd like to do is first to Dockerize - meaning we would extend to provide Dockerfiles so that users can quickly spin up containers. I've already started a bit of this, and will continue with pynetdicom3 (but I'd really like it to be pynetdicom).
- There shouldn't be any features in pynetdicom that are missing in pynetdicom3 (as far as I'm aware).
- There are naming differences at pretty much all levels. Variables, classes, methods and modules have almost all been refactored and renamed to meet PEP8, although there are a few outstanding changes still to be made.
- I intend to keep working on pynetdicom3, but I've been mostly focusing on helping to get pydicom to v1.0 (because its more fun).
hey @scaramallion - I am working on one of our first applications using pydicom and pynetdicom3, and things are working great! @patmun do you see any reason that we can't essentially glob pynetdicom3 into pynetdicom, and start working together on that as a base? And @scaramallion - what are the updates with pydicom / do you need any help?
It would be really great to have some oomph behind python + dicom, and I think these two projects can be a strong base for that. We can extend the base tools to contained-based apps, too. Neuroimaging really flourished when python entered the scene, and now nipy has been the base for nibabel, nilearn, nipype, and now containers with things like bids apps, and many more! A programmer / student / new researcher should be able to do a Google search and hit these tools (instead of the old crusty wikis about the dicom standard they hit now), and be encouraged to use them as a starting base. What are your thoughts? I think to start we might think about making a Github organization to bring repos and people together, if one doesn't already exist.
I have no problem merging pynetdicom3 into pynetdicom (or perhaps rename pynetdicom3 into pynetdicom). I think too that having different forks with different names is a source of confusion, and this situation should be resolved asap.
I'm actually very happy to see motivated people who can give this project a new start. I personally don't have much time to devote to pynetdicom at the moment, and if you guys are willing to take over, by all means go ahead!
I would suggest the following for an eventual merge:
- freeze the actual pynetdicom codebase in a pip installable release (perhaps 0.9.0) for people who already use that code and don't want to change right now.
- merge pynetdicom3 and improve until its ready for a 1.0.0 release.
Feel free to bring your own suggestions ...
2017-05-23 2:46 GMT-04:00 Vanessa Sochat [email protected]:
hey @scaramallion https://github.com/scaramallion - I am working on one of our first applications using pydicom and pynetdicom3, and things are working great! @patmun https://github.com/patmun do you see any reason that we can't essentially glob pynetdicom3 into pynetdicom, and start working together on that as a base? And @scaramallion https://github.com/scaramallion - what are the updates with pydicom / do you need any help?
It would be really great to have some oomph behind python + dicom, and I think these two projects can be a strong base for that. We can extend the base tools to contained-based apps, too. Neuroimaging really flourished when python entered the scene, and now nipy http://nipy.org/ has been the base for nibabel http://nipy.org/nibabel/, nilearn https://nilearn.github.io, nipype http://nipype.readthedocs.io/en/latest/, and now containers with things like bids apps http://bids-apps.neuroimaging.io/apps/, and many more! A programmer / student / new researcher should be able to do a Google search and hit these tools (instead of the old crusty wikis about the dicom standard they hit now), and be encouraged to use them as a starting base. What are your thoughts? I think to start we might think about making a Github organization to bring repos and people together, if one doesn't already exist.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/patmun/pynetdicom/issues/66#issuecomment-303305634, or mute the thread https://github.com/notifications/unsubscribe-auth/ANgw1tfYVOLMja166AmTAOo4VT-yM3TKks5r8oC5gaJpZM4NhAJN .
-- Patrice Munger
This sounds great! If the package is already on pip, then you should be able to freeze it's current state and then do one final version (if you want). I would agree, and suggest the following:
- final push to pip for version 0.9.0 to support current users of the package
- we would then want to have pynetdicom3 --> pynetdicom on the pydicom organization, and pynetdicom3 would then be the package renamed to pynetdicom and served via pip for versions later than 0.0.9. I think we have a few options for this:
- Move this repo: Move the actual repo over to the pydicom organization. I would also be happy to fork it over when you are finished up, and then this will (sort of) become your working fork. In this case, we would need to then do a PR to this repo with the entire pynetdicom3 code base.
- Do the same, but move pynetdicom3. @scaramallion - it might make sense for me to fork pynetdicom3, rename it pynetdicom, and then make little tweaks to rename things. @patmun, you have ownership to the pypi pushing, so probably the first thing we should do is a version 0.1.0 of pynetdicom that is essentially pynetdicom3.
Do you have preference for each of the above, both @patmun and @scaramallion? I'm happy to just fork and then do updates/tweaks - our first goal should be just moving/renaming stuff to be in the proper place, then I'd like to make some updated docs and an organization page for pydicom.
Just another comment, regarding docker images. @vsoch, perhaps I don't understand how you want to use them. We have to keep in mind that pynetdicom is not a dicom server or client. It's a tool that allows dicom clients and servers (or more generally application entities) to be writtten. I would see how a specific application entity written with pynetdicom could be deployed on docker, but I think these things should be kept as separate projects.
That is correct, right now I'm working on a dockerized application (meaning a docker image with uwsgi, a database, and web server) for which pynetdicom is used within the application for different functions. So to be clear - we would provide Docker images/compose specs to deploy simple, container based tools that use pynetdicom/pydicom. That is one of the reasons I'm advocating for the pydicom organization - we would want these things to be separate repositories.
hey @patmun - I forked the pynetdicom3 repo over to https://github.com/pydicom/pynetdicom3, so when you are ready, I'll rename to pynetdicom, and then do the work to update the code to remove the 3. @scaramallion , let us know your preference for steps after that. I'm happy to keep your branch as the master and PR to it, updating my master as necessary, or to have you take primarily management of the repo under the pydicom organization, with the standard protected master and development branch, and only you would have the final say in merging. I think @darcymason is hopefully on board too to do something similar, and then we will have nicer resolution of "the place to find dicom and python." I can take care of making consolidated docs, or minimally a central resource that links to the different docs, when I have a sense of everyone's preferences.