Move code quality dependencies to separate environment #380
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
Thank you for contributing to
QuantumToolbox.jl! Please make sure you have finished the following tasks before opening the PR.make test.juliaformatted by running:make format.docs/folder) related to code changes were updated and able to build locally by running:make docs.CHANGELOG.mdshould be updated (regarding to the code changes) and built by running:make changelog.Request for a review after you have completed all the tasks. If you have not finished them all, you can also open a Draft Pull Request to let the others know this on-going work.
Description
Here I move the code quality dependencies (Aqua.jl and JET.jl) to a separate environment. In this way we simplify the dependency structure of the package, trying to make it compatible to the Julia nightly tests (that were failing due to JET).
This is different from the implementation we adopted months ago, where we were running
Pkg.add(["Aqua", "JET"])with an increase of run test times. Here I actually create a separate environment for that, which allows to have everything already precompiled.I have also changed the order of the tests. I think that having the core tests first is better, since we are first interested in the actual working changes, and only after in improving the code quality.