No such file or directory: '/opt/conda/lib/python3.9/site-packages/ronswanson/data/log_theme.ini'

[volodymyrss]

• ronswanson version: 0.2.5 (pip install ronswanson as of right now)
• Python version: 3.9
• Operating System: bullseye/sid

Description

Tried to follow the example in the doc http://jmichaelburgess.com/ronswanson/notebooks/ronswanson.html#Example-with-a-Band-function

in relation to https://github.com/openjournals/joss-reviews/issues/4969

What I Did

FileNotFoundError                         Traceback (most recent call last)
Input In [3], in <cell line: 5>()
      3 import numpy as np
      4 from astromodels import Band
----> 5 import ronswanson as dukesilver
      8 class BandSimulation(dukesilver.Simulation):
      9     def __init__(
     10         self,
     11         simulation_id: int,
   (...)
     14         out_file: str,
     15     ) -> None:

File /opt/conda/lib/python3.9/site-packages/ronswanson/__init__.py:9, in <module>
      6 __email__ = 'jburgess@mpe.mpg.de'
      8 from ._version import get_versions
----> 9 from .database import Database
     10 from .simulation import Simulation
     11 from .simulation_builder import SimulationBuilder

File /opt/conda/lib/python3.9/site-packages/ronswanson/database.py:12, in <module>
      9 from astromodels.utils.logging import silence_console_log
     10 from tqdm.auto import tqdm
---> 12 from ronswanson.grids import Parameter, ParameterGrid
     13 from ronswanson.utils.color import Colors
     15 from .utils.logging import setup_logger

File /opt/conda/lib/python3.9/site-packages/ronswanson/grids.py:9, in <module>
      6 import numpy as np
      7 import yaml
----> 9 from .utils.logging import setup_logger
     11 log = setup_logger(__name__)
     14 @dataclass(frozen=True)
     15 class EnergyGrid:

File /opt/conda/lib/python3.9/site-packages/ronswanson/utils/logging.py:25, in <module>
     16         return logRecord.levelno != self.__level
     19 _console_formatter = logging.Formatter(
     20     ' %(message)s',
     21     datefmt="%H:%M:%S",
     22 )
---> 25 mytheme = Theme().read(get_path_of_data_file("log_theme.ini"))
     26 console = Console(theme=mytheme)
     28 ronswanson_console_log_handler = RichHandler(
     29     level=ronswanson_config.logging.level,
     30     rich_tracebacks=True,
     31     markup=True,
     32     console=console,
     33 )

File /opt/conda/lib/python3.9/site-packages/rich/theme.py:69, in Theme.read(cls, path, inherit)
     58 @classmethod
     59 def read(cls, path: str, inherit: bool = True) -> "Theme":
     60     """Read a theme from a path.
     61 
     62     Args:
   (...)
     67         Theme: A new theme instance.
     68     """
---> 69     with open(path, "rt") as config_file:
     70         return cls.from_file(config_file, source=path, inherit=inherit)

FileNotFoundError: [Errno 2] No such file or directory: '/opt/conda/lib/python3.9/site-packages/ronswanson/data/log_theme.ini'

https://renkulab.io/projects/vladimir.savchenko/ronswanson-review/files/blob/Untitled.ipynb

[grburgess]

Uff. I thought I had fixed that. Will correct.

[grburgess]

@volodymyrss should be fixed in the last upload to pypi. However, it might be best to clone or install directly from master if there are any other bugs at the moment for faster turnaround. Thanks!

[volodymyrss]

Thanks it works now. I wonder how it works in relation to https://github.com/openjournals/joss-reviews/issues/4969 , it has to be somehow well-defined version which is being reviewed. As it's iterative, it would be the master branch. But some commands in the doc would not work until the version is uploaded. Maybe this is not imporatant. It's more of a question to @dfm.

[dfm]

@volodymyrss the best approach is to review the development version of the software and then we always tag a new release at the end of the review to archive the reviewed version.

[volodymyrss]

@volodymyrss the best approach is to review the development version of the software and then we always tag a new release at the end of the review to archive the reviewed version.

Ok, I see, the comments/issues can be on master.

But I suppose the approval should be on a fixed revision, right? Else there can be a change on the master branch which is not approved. How do I track what I am approving?

In principle, this is the case not only for final approval but for every qualification.

E.g. if I check "[ ] Installation: Does installation proceed as outlined in the documentation?", how do I indicate that it this particular version which proceeds, but not the other one?

edit: it's like in the PR: a new commit can be made to break the approval.

[dfm]

@volodymyrss Good question! We typically are not strict about that for JOSS reviews - you're definitely not expected to go through the full checklist a second time when there is a final version minted. I'd say that this is partly because of logistics (the scope is too broad, and it's hard to synchronize the two reviews, for example), but also partly because the point of a JOSS review is more to provide constructive feedback than to bring a specific judgement. From my perspective, it's totally sufficient to make sure that at the time you're going through it, the development branch satisfies the criteria in the checklist. That being said, if there are elements that are brittle or give you other reasons to be concerned, it's good to note that, and when I'm reviewing I do sometimes quickly go through the checklist one last time before signing off, but that's certainly not required! Please let me know if you have further questions - I'm happy to continue this conversation!

[volodymyrss]

@volodymyrss Good question! We typically are not strict about that for JOSS reviews - you're definitely not expected to go through the full checklist a second time when there is a final version minted. I'd say that this is partly because of logistics (the scope is too broad, and it's hard to synchronize the two reviews, for example), but also partly because the point of a JOSS review is more to provide constructive feedback than to bring a specific judgement. From my perspective, it's totally sufficient to make sure that at the time you're going through it, the development branch satisfies the criteria in the checklist.

I see, thanks.

That being said, if there are elements that are brittle or give you other reasons to be concerned, it's good to note that, and when I'm reviewing I do sometimes quickly go through the checklist one last time before signing off, but that's certainly not required! Please let me know if you have further questions - I'm happy to continue this conversation!

Installation is quite likely to break in the future, especially if the requirements are not frozen. I suppose this is normal and not a fault of the software. Evolving requirements may even change the behavior, or at least performance. If we are concerned here with making the review reproducible and verifiable, I'd attach some form of environment snapshot, with all fixed versions, in a container.

But at minimum, I could point out the revision I am looking at when making a statement. Maybe your bot could make use of this information in the future.

[dfm]

Great - totally agreed! And thanks for the suggestion - I'll bring this point up with the other JOSS editors to see how we'd like to handle these versioning issues that you've brought up. Thanks again!!

[volodymyrss]

Thanks to you! This is interesting.