I've seen the following confusion happen frequently (at least twice to my knowledge over the last few weeks which is too high in my opinion). The person ends up in a state where their filesystem looks like
- path/to/ldmx/
- .denv/ # development denv created by running just init
- ldmx-sw/
- .denv/ # production denv created by running denv init ldmx/pro:<version> within ldmx-sw
This leads to the very confusing situation where denv fire can work from within ldmx-sw even if its not built (since it reads from the production image denv) while just fire will not work since it is using the development image and ldmx-sw is not built yet.
Short-Term Solution
If you find yourself in this state, delete the production image denv within ldmx-sw and (if you still need it), re-create it in another directory.
rm -r ldmx-sw/.denv
mkdir my-other-project
cd my-other-project
denv init ldmx/pro:<version>
Long-Term Solution
The solution is to keep these two denvs separate. Literally any other directory other than ldmx-sw can be used for the ldmx/pro denv so maybe this can be resolved by updating the notes on the website to emphasize this point?
We could update the init recipe to specifically make sure that no denv is already created erroneously within ldmx-sw.
I'd like to avoid a hardcoded check within denv since I use it for other (non-LDMX or ldmx-sw) projects. Another idea is to avoid keeping the development denv outside of ldmx-sw. This choice is a relic of the ldmx suite of bash functions and could be avoided with how denv is designed. Putting the ldmx-sw denv within ldmx-sw would then help avoid this issue - you would need to overwrite the denv in ldmx-sw to get into a broken state like this and denv warns you before you would do so.
For the medium term, I've added a warning to the getting started area informing anyone getting started to avoid running denv init within ldmx-sw itself.
I've seen the following confusion happen frequently (at least twice to my knowledge over the last few weeks which is too high in my opinion). The person ends up in a state where their filesystem looks like
This leads to the very confusing situation where
denv fire
can work from within ldmx-sw even if its not built (since it reads from the production image denv) whilejust fire
will not work since it is using the development image and ldmx-sw is not built yet.Short-Term Solution
If you find yourself in this state, delete the production image denv within ldmx-sw and (if you still need it), re-create it in another directory.
Long-Term Solution
The solution is to keep these two denvs separate. Literally any other directory other than
ldmx-sw
can be used for theldmx/pro
denv so maybe this can be resolved by updating the notes on the website to emphasize this point?We could update the
init
recipe to specifically make sure that no denv is already created erroneously within ldmx-sw.https://github.com/LDMX-Software/ldmx-sw/blob/6c08a49cb7a0bd8cff03f3e838f91f0536261c99/justfile#L85-L100
I'd like to avoid a hardcoded check within
denv
since I use it for other (non-LDMX or ldmx-sw) projects. Another idea is to avoid keeping the development denv outside of ldmx-sw. This choice is a relic of theldmx
suite of bash functions and could be avoided with howdenv
is designed. Putting the ldmx-sw denv within ldmx-sw would then help avoid this issue - you would need to overwrite the denv in ldmx-sw to get into a broken state like this anddenv
warns you before you would do so.