removing Pyne import when not required

[bam241]

removing import that are not used when importing PyNE.

useful when those modules are neither build nor required :)

[nuclearkatie]

LGTM, thanks @bam241!

[gonuke]

I think I found a few more places, since we're doing this here.

[gonuke]

I don't think we need these here, either.

[gonuke]

Not sure why this needs any of PyNE?

[abachma2]

I hope you don't mind @bam241, but I went ahead an updated your branch to be even with the main branch, then made the changes requested by @gonuke. I think this is a very useful PR, so I'm happy to continue to work on this to get it merged.

[bam241]

I hope you don't mind @bam241, but I went ahead an updated your branch to be even with the main branch, then made the changes requested by @gonuke. I think this is a very useful PR, so I'm happy to continue to work on this to get it merged.

Not an issue with me, I am actually glad some of my old work could be useful!
(I didn't know you could use my branch and commit on it. The commits actually leave on my fork)

[gonuke]

This is now failing tests, but that may be because of upstream changes... Let's wait until the CI refactor is done and take another look

[abachma2]

I've merged in the main branch, which includes the CI work @bennibbelink did. It looks like some of the tests still aren't passing, so I'll work on this.

[abachma2]

It looks like it has trouble building Cymetric, and the error is

buildx failed with: ERROR: failed to solve: error writing layer blob: unexpected status from POST request to https://ghcr.io/v2/cyclus/cymetric_20.04_apt/cymetric/blobs/uploads/: 403 Forbidden

Is this something with the new CI work you did @bennibbelink?

[bennibbelink]

Is this something with the new CI work you did @bennibbelink?

@abachma2 Yes it is. Cymetric is building successfully but the workflow is attempting to push an image (the layer cache) to the cyclus GHCR. Since this PR is coming from a fork it doesn't have permission. This is a flaw in the new CI strategy, I will try to find a solution quickly

[abachma2]

That makes a lot of sense. If you can't figure out a way to allow this, we should really add a note to all of the contributing documentation for the Cyclus, Cycamore, and Cymetric repos that PRs need to come from the cyclus remote to allow running the tests.

[bennibbelink]

I see two ways to resolve the 403:

1. Read/write image caches to the GHCR of github.repository_owner. This would require collaborators to have packages enabled in their GitHub account, and it would not provide the same caching benefits if collaborators don't contribute frequently (thus updating their caches). I don't think this is a good solution
2. When we --cache-to the cyclus GHCR we can include the ignore-error option. This ignores errors caused by failed cache exports. This way a collaborators workflow would pull the cache from cyclus' GHCR but not push a cache anywhere (because it fails). Thus the caches would only get updated when a workflow is run from the upstream repo which will happen on any PR coming from a cyclus branch OR any push to main. I think this the better solution... In most cases the only cached layers that are used are those that build the "dependency image", so we would only lose some caching benefits when collaborators are modifying the dependencies (this already exists in our CI strategy, so not much changes)

The second solution should be really easy to implement and fix the issue. I'll go ahead and make a PR so we can get this resolved quickly

[bennibbelink]

This exposes another issue in the CI refactor - the :ci-image-cache images that are pushed to GHCR will fail from forks too. This should be an easy fix as well, we will just keep the images local to the GitHub runner instead of pushing to the package registry

[abachma2]

I would agree that the second method is preferred. Thanks for taking care of all of this.

[github-actions]

Build Status Report

Build FROM cycamore_20.04_apt/cycamore:latest - Failure ❌
Build FROM cycamore_20.04_apt/cycamore:stable - Failure ❌
Build FROM cycamore_20.04_conda/cycamore:latest - Failure ❌
Build FROM cycamore_20.04_conda/cycamore:stable - Failure ❌
Build FROM cycamore_22.04_apt/cycamore:latest - Failure ❌
Build FROM cycamore_22.04_apt/cycamore:stable - Failure ❌
Build FROM cycamore_22.04_conda/cycamore:latest - Failure ❌
Build FROM cycamore_22.04_conda/cycamore:stable - Failure ❌

[abachma2]

It looks like the CI changes made in #193 worked, and the tests for Cymetric run and pass. We need to figure out the Cycamore tests, but I'm assuming it's the same issue as what #193 addressed.

Does this PR need any more reviews before merging?

[gonuke]

I'm confident this is all OK based on this testing, and we'll figure out the upstream/downstream testing as we go.