Closed SimonBiggs closed 4 years ago
jrkerns
commented
4 years ago Yup. I know there was some reason for pinning it that way but I can't remember or find out =)
I updated Travis for the various versions and it should all be good there. Working on the next major version release
SimonBiggs
commented
4 years ago Awesome thanks James :)
On Thu., 16 Apr. 2020, 4:12 am James Kerns, notifications@github.com wrote:
Yup. I know there was some reason for pinning it that way but I can't remember or find out =)
I updated Travis for the various versions and it should all be good there. Working on the next major version release
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jrkerns/pylinac/issues/275#issuecomment-614196386, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSBK6ZGXWQODTFBQRW6ZJ3RMX2I7ANCNFSM4MIIDPKQ .
SimonBiggs
commented
4 years ago Thanks James :)
Hi @jrkerns,
Once https://github.com/jrkerns/pylinac/issues/268#issuecomment-613198392 lands I believe the best way forward will be for me to depend upon pylinac within PyMedPhys for my Wlutz algorithm. I still want to have an independent implementation with a significantly different approach at some point in the future, but current world events have adjusted priorities here.
Before having PyMedPhys depend on pylinac I was hoping to have the dependency upper limits removed from pylinac itself. So as to avoid downstream dependency hell I am aiming to pin packages as minimally as possible, instead allowing application developers to do their own pinning.
As such, I was hoping the following two upper limits may be able to be removed:
Any thoughts on your end?
Cheers, Simon