-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enterprise falls back to PINT if no TEMPO2 #340
base: dev
Are you sure you want to change the base?
Conversation
This is particularly valuable in light of #339 ; no seg faults if no TEMPO2. |
Still to do:
|
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #340 +/- ##
==========================================
- Coverage 88.37% 88.33% -0.05%
==========================================
Files 13 13
Lines 3012 3026 +14
==========================================
+ Hits 2662 2673 +11
- Misses 350 353 +3
Continue to review full report at Codecov.
|
Question: how do we make |
The no-tempo2 installation is a bit of a hack, as we can't really tell pip "don't bother with this required dependency" and so it insists on installing Long-term, we could make the tempo2 dependency optional - Short-term, we might be able to trick |
To get adequate coverage of the patch I added a few tests; several of them are XFAIL because the behaviour of |
The CI will still require high coverage percentages, but it is able to combine multiple runs (tempo2-only, pint-only, both) to cover everything.
We have three conditions for coverage:
I think the third requirement is awkward and inconvenient from a CI point of view, although it is one that can be checked locally with Perhaps we could have two makefile targets: |
The changes to the code base are quite minor; just |
I'm not sure what's up with the HTTP 404s - this occurs when astropy is trying to update its leap seconds file. It doesn't happen on my local machine, and it seems to only happen with the old python 3.7, pint 0.8.8, astropy 4.3.1 version; with astropy 5.2.1 the problem disappears. There were substantial upgrades to astropy's remote data fetching with astropy 5, so this may help explain why the problem only occurs with very old versions. |
Something has happened to prevent the coverage upload from the "no tempo2" version. I'm not sure what; maybe a passing network problem. |
I do not like the hoops we are jumping through here to have libstempo installed by default, but to allow for a no tempo2 version. Our situation is perhaps somewhat unique that we have two independent packages, neither of which is ideal:
Unfortunately, Python's packaging system doesn't directly support conditional dependencies based on the presence of other packages at install time. The closest built-in feature is the extra requires functionality, with those square brackets. My suggestion to deal with this in a consistent way would be to
Of course the problem with this approach is that some build scripts and container scripts currently rely on libstempo being installed automagically, so if we make this change there will be things that break. |
This has three significant changes:
Pulsar(par, tim)
without specifying PINT vs TEMPO2, one of two things will happen:BINARY T2
) are skipped.xfail
).In short: you can use Enterprise transparently without TEMPO2. Also: a CI run now checks that Enterprise runs fine using PintPulsar for everything, and another checks that Enterprise runs fine without PINT. (Getting Enterprise to install when one or other dependency is missing is awkward but doable.)