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

Precompilation error when SatelliteToolbox and get_iers_eop are used as dependencies #75

Closed
disberd opened this issue Feb 4, 2022 · 2 comments

Comments

@disberd
Copy link
Contributor

disberd commented Feb 4, 2022

Hello,

I am using SatelliteToolbox as dependency in one of my packages (thanks for developing this!) and encountered a precompilation error when trying to import my own package.

The encountered error is:

ERROR: LoadError: Evaluation into the closed module `SatelliteToolbox` breaks incremental compilation because the side effects will not be permanent. This is likely due to some other module mutating `SatelliteToolbox` with `eval` during precompilation - don't do this.

And looking at the stacktrace is triggered when calling this macro inside the specific get_iers_eop_iau_1980 subfunction:

_eop_iau1980 = @RemoteFile(
@eval($url),
file="EOP_IAU1980.TXT",
updates=:daily
)

But the same happens with the other function get_iers_eop_iau_2000A slightly below the same source file as it share the same macro call to @RemoteFile.

You can easily try to reproduce the same error by creating a temp package, add SatelliteToolbox to its environment and then have your module file simply be:

module SatToolbox_error

using SatelliteToolbox

get_iers_eop(Val(:IAU2000A))

end # module

The error above will pop up as soon as you try to precompile your temp package (called SatToolbox_error above).

It seems the problem indeed comes from the use of @eval above inside @RemoteFile. Luckily that is not needed, and I already tested a small modification to properly use @RemoteFile without needing @eval.

The proposed fix (which correctly removes the pre-compilation errors) is submitted in a separate PR (#76)

@rconnorjohnstone
Copy link

This error was fixed on the main branch as of Feb 4, but the last release of this package was in January. Would it be possible to issue a new "official" version that contains this fix? It's inconvenient to not be able to use a specific version number in my Project.toml files, but instead have to specify the master branch manually.

@ronisbr
Copy link
Member

ronisbr commented Oct 6, 2022

Oops! Sorry! I will do this.

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

No branches or pull requests

3 participants