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

Support store-dir and package-env in cabal.project #10184

Open
hasufell opened this issue Jul 7, 2024 · 11 comments
Open

Support store-dir and package-env in cabal.project #10184

hasufell opened this issue Jul 7, 2024 · 11 comments

Comments

@hasufell
Copy link
Member

hasufell commented Jul 7, 2024

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 of cabal.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

@andreabedini
Copy link
Collaborator

The tl;dr is that, as it stands now, they are not part of the project configuration (which is ProjectConfig).

With respect to store-dir; I had left some comments in the code.

-- *Important:* You can notice how some project config options are needed to read the
-- project config! This is evident by the fact that "rebuildProjectConfig"
-- takes "HttpTransport" and "DistDirLayout" as parameters. Two arguments are
-- infact determined from the CLI alone (in "establishProjectBaseContext").
-- Consequently, project files (including global configuration) cannot
-- affect those parameters!
. One could say it's part of the environment where the project lives more than the project configuration itself. E.g. same ProjectConfig with two different StoreLayouts would build "exacty" the same (take this with a grain of salt).

With respect to package-env; this is a flag (cinstEnvironmentPath) specific to v2-install. I am not sure what meaning it would have inside ProjectConfig.

AFAIU ProjectConfig is based on the content of the global configuration (which is indeed parsed into a ProjectConfig as well). Perhaps there is a distinction between "project configuration" and "local configuration of the build tool" that hasn't been explored.

@hasufell
Copy link
Member Author

Can we get a conceptual decision on this, so someone can go ahead and provide a PR?

@ulysses4ever
Copy link
Collaborator

Will it suffer the same issue that stopped --builddir from inclusion into project files?

@hasufell
Copy link
Member Author

Will it suffer the same issue that stopped --builddir from inclusion into project files?

Could you expand why?

@ulysses4ever
Copy link
Collaborator

Why what? I didn't make any statement, I only asked a question.

@gbaz
Copy link
Collaborator

gbaz commented Jul 29, 2024

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.

@geekosaur
Copy link
Collaborator

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 cabal.project(.local).

@ivanperez-keera
Copy link
Contributor

Gentle bump

@geekosaur
Copy link
Collaborator

geekosaur commented Sep 12, 2024

I think this is not happening soon because

  1. we're currently making a lightning release for the GHC devs
  2. it will require a fair amount of work, because cabal's architecture isn't up to this rearrangement currently (in particular, I think at present store-dir needs to be fixed before the project file is read, and as such may be used during parsing of package stanzas).

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 *.cabal files in project files).

@hasufell
Copy link
Member Author

I think this is not happening soon because

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.

There are a couple of other open requests that will require rethinking how and where project files fit into cabal's architecture

This ticket is definitely not about refactoring the current architecture. I want to avoid scope creep.

I think at present store-dir needs to be fixed before the project file is read

@andreabedini do you have further insights into this?

@geekosaur
Copy link
Collaborator

geekosaur commented Sep 12, 2024

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?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants