-
Notifications
You must be signed in to change notification settings - Fork 32
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
Problematic try exception import block #350
Comments
This is misleading to new people if .xenon_secrets can't be found for some reason. They check if utilix installed, it is, but error is about utilix not in namespace. |
Hi Chris, I tend to agree, I've also had incomprehensible errors due to this sloppy importing. I think the root issue is how utilix is initialized, rather than doing things sloppy here, I'd argue that we have to change this on the utilix side first. By the way, there is a warning raised: Line 10 in 4cd5887
I think these two PRs should work: |
I actually think the root issue is that we don't allow travis / github actions access to our database. @tunnell I think we could fix all these issues and improve our testing if we allow access to our database using a read only account, I haven't found any convincing reason not to allow this access. True, we could setup some database in travis I don't have the time to do it while I can simply add an encrypted password and user into the testing (I know how to for both Travis and github actions). This is becoming an increasingly pressing issue, for example, we cannot test the posrec algos because we set their files in our database. If you approve (and possibly also @darrylmasson ), I will set this up (use a read-only that has access to the database to do tests). NB: by the way we are actually already a write account to do some uploads for admix. |
@jorana we do have access to the database globally right? We can't write to the database but two of the mirrors are accessible. Or am I missing something? |
Some accounts are limited in where they can be used from, but nt_analysis (for instance) has read-only access and can be used from anywhere. |
Yeah, for some reason we have not used any database integration (because of performance/privacy/fear of malicious access??) . The problem is not that we cannot, the problem is if I'm not sure if the main database experts (@darrylmasson @tunnell ) are ok with the travis testing to have access to our database to read. Apart from the performance I don't see any argument that makes sense. But even the performance should be fine. |
Yes, that's fine. Just use TravisCI encrypted environmental variables. Write users have IP restrictions, so you'd have to use read-only. That specific issue I raised should alter the try-import loop. Either check explicitely if TravisCI, which sets an environmental variables. If Travis, print warning. If not travis, raise exception. OR do what you're saying. I meant for a simpler solution. Catching two rather generic exceptions is just dangerous since the program can get in weird states. I didn't mean for big solution |
That specific issue I raised should alter the try-import loop. Either check explicitely if TravisCI, which sets an environmental variables. If Travis, print warning. If not travis, raise exception. OR do what you're saying. I meant for a simpler solution |
Solved in #360 |
straxen/straxen/corrections_services.py
Line 8 in 2b32ba5
If utilix isn't installed, it doesn't tell you. However, if utilix fails to load for some reason, then it won't tell you... you can check if Travis through environmental variables, or at least print a warning that there was an exception? You can log exceptions without reraising.
The text was updated successfully, but these errors were encountered: