-
Notifications
You must be signed in to change notification settings - Fork 697
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
Support store-dir
and package-env
in cabal.project
#10184
Comments
The tl;dr is that, as it stands now, they are not part of the project configuration (which is With respect to store-dir; I had left some comments in the code. cabal/cabal-install/src/Distribution/Client/ProjectPlanning.hs Lines 324 to 329 in 2fbfd55
ProjectConfig with two different StoreLayout s would build "exacty" the same (take this with a grain of salt).
With respect to package-env; this is a flag ( AFAIU |
Can we get a conceptual decision on this, so someone can go ahead and provide a PR? |
Will it suffer the same issue that stopped |
Could you expand why? |
Why what? I didn't make any statement, I only asked a question. |
i think we should in spirit agree to adding the fields. that said, i think in the resultant sandbox-like workflow they should be added to cabal.project.local since they don’t make sense to check in to source. also, in my cursory read of the linked ticket, i don't think the same caching considerations should apply here. |
Right, I don't see either one affecting caching, so this should be okay modulo their not being part of the things we currently initialize from |
Gentle bump |
I think this is not happening soon because
There are a couple of other open requests that will require rethinking how and where project files fit into cabal's architecture (e.g. #9230 / #10016 / #10253, which would require some way to put information that currently is associated with |
The main idea of this ticket wasn't to ask cabal devs to do it. But to ask for consensus before a volunteer might work on it, so that no one wastes their time. Can I assume that there is basic consensus? Ofc an implementation may open further doubts/questions.
This ticket is definitely not about refactoring the current architecture. I want to avoid scope creep.
@andreabedini do you have further insights into this? |
I think @gbaz does. And as @gbaz said, we have agreement in spirit. My worry is that it might be a nightmare to implement in cabal as it currently exists. We keep running into unexpected nasty interactions with things that "ought to be" easy (I think @philderbeast can attest to a few of these?). |
Describe the feature request
It seems like an oversight that these aren't supported. I would have expected that
cabal.project
is kind of a superset ofcabal.config
.I don't really see any problems allowing them to be set at the project level. It actually seems kind of intuitive to do so.
Additional context
This is needed to implement a prototype for cabal sandboxes, see: #10098
The text was updated successfully, but these errors were encountered: