Removes blocking behavior when trident is not configured #142
Conversation
…his necessary has now been addressed.
| @@ -161,14 +159,6 @@ def make_simple_ray(dataset_file, start_position, end_position, | |||
| and :lines:='all', it will add every ion of every element up to Zinc. | |||
| Default: None | |||
|
|
|||
| :ionization_table: string, optional | |||
There was a problem hiding this comment.
I removed this since I realized it is not actually used at all. I guess we could deprecate and leave in, but I seriously doubt anyone ever manually sets the ionization table when generating a ray and just uses the default setup in their config file.
There was a problem hiding this comment.
I could see how this could be useful for making comparisons between multiple ionization tables. It's hard to know for sure that no one is using it. I'd say at least it should be deprecated first.
| @@ -450,16 +450,3 @@ def make_onezone_ray(density=1e-26, temperature=1000, metallicity=0.3, | |||
| ray.domain_right_edge = ray.domain_right_edge.to('code_length') | |||
|
|
|||
| return ray | |||
|
|
|||
There was a problem hiding this comment.
It appears that the astropy error that led to this kluge has been fixed in the last three years. I cannot find the PR that fixed it in astropy, but I can now import trident in its source directory and it doesn't fail out the way it used to. So I'm pulling this.
Pull Request Test Coverage Report for Build 1141
💛 - Coveralls |
| @@ -161,14 +159,6 @@ def make_simple_ray(dataset_file, start_position, end_position, | |||
| and :lines:='all', it will add every ion of every element up to Zinc. | |||
| Default: None | |||
|
|
|||
| :ionization_table: string, optional | |||
There was a problem hiding this comment.
I could see how this could be useful for making comparisons between multiple ionization tables. It's hard to know for sure that no one is using it. I'd say at least it should be deprecated first.
|
@brittonsmith I addressed these comments. Is it possible for you to try this out locally to ensure this behaves the way you want it to, since you were the genesis of Issue #57 which spawned this PR. |
| the development version of Trident requires the development version of yt, both | ||
| built from source. Don't worry if you want to change later, you can always | ||
| switch between the two versions easily enough by following the directions in | ||
| :ref:`uninstallation`. | ||
|
|
||
| .. _step-1: |
There was a problem hiding this comment.
Since yt is a hard dependency for trident, it should be possible to just to pip install trident to get stable releases of both codes. It might be useful to add a suggestion to try that before installing yt and trident separately.
There was a problem hiding this comment.
Looks good to me. I only had one small comment about installation. I tested importing without a .trident directory and it worked. It might be a good idea to add a test for this, i.e., an additional command in the circleci script that tries to import trident before putting the config file in place.
This PR addresses Issue #57 and makes it so that Trident can operate minimally even when it hasn't been configured. Prior to this, Trident would block and require user input in order to proceed, which meant that it didn't play well with other codes as a dependency or with automatic documentation generation with Readthedocs.
This PR removes that blocking behavior. When initially imported, trident prints a verbose message to the user requesting that they run a command to automatically generate the config file and download the ion_balance file. Furthermore, if this is ignored, Trident tries to operate without this information. If specific functions require ion balance information, it raises an appropriate exception and halts.
This started out as a PR to update the installation documentation, which is why there is a slight update to the docs, but I figured this blocking behavior should be addressed first, and then the rest of the install docs can be updated.