Skip to content
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

Explicit imports #55

Open
cgarling opened this issue Feb 13, 2025 · 1 comment · May be fixed by #60
Open

Explicit imports #55

cgarling opened this issue Feb 13, 2025 · 1 comment · May be fixed by #60

Comments

@cgarling
Copy link
Member

We are doing most of our importing from dependencies with generic using statements (e.g., using Unitful) which makes it hard for people not familiar with the dependencies (e.g., me) to tell where some methods/definitions are coming from. By using explicit imports or qualified names (e.g., using Unitful: m, <etc...> or import Unitful as u; u.m we make this discovery process easier -- e.g., if I see an unqualified interpolate method being used in our code, I can go to the imports block and see where it is being imported from quickly.

Similarly I would move import statements out of included files like color_law.jl and dust_maps.jl and put all the imports in the same place at the module level in the DustExtinction.jl file. Having all the imports in one place simplifies the process of auditing the dependencies so you don't have to crawl through all the source files to find all the import statements.

I think this would improve maintainability / onboarding for new maintainers.

@icweaver
Copy link
Member

100% agree. Might even be a good chance to try out Eric's package. It's been on my radar since the announcement on discourse

@icweaver icweaver linked a pull request Feb 21, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants