Describe the bug
There needs to be a way to tell Cabal on a per-project basis "use this local repository instead of Hackage" rather than "in addition to Hackage".
To Reproduce
Define your local repository (e.g., a mirror of Hackage), to to the project dir, and do cabal update.
Observe that it reaches to both Hackage and the repository you defined.
Expected behavior
Go only to my locally-defined repository.
System information
Irrelevant, but
cabal-3.0.0.0, ghc-8.8.3 Additional context
Sometimes it's convenient when Cabal can reach both. In other times (isolated/disconnected subnets) it cannot go to Hackage, so there should be a way to stop it from doing that.
Solution should not affect other projects on the same host, ideally - be truly per-project. Though, if worst comes to worst, messing with ~/.cabal/config would be acceptable (e.g., if the machine is disconnected anyway).
As far as I know, you indeed can accomplish this via ~/.cabal/config. And additionally you can pass a command line flag to use a different cabal config than the standard one.
So, it has to be at ~/.cabal/config level? Cannot be done on cabal.project level only?
Could you give an example of Cabal invocation that points at a different config file?
Also, if I point at a different "global" config - do I still need to define this alternative repository in the cabal.project file, or it can be omitted on this case?
Thanks!
There are no currently way to specify which repositories are used. I.e. all are used, ~/.cabal/config and cabal.project data is combined.
But it's quite top on my todo list, so I'm confident we'll have a way to specify the active repositories in 3.4. (We kind of need that for testing too).
no currently way to specify which repositories are used ... But it's quite top on my todo list
Thank you!!
In the meanwhile, what command line parameter can I use to point Cabal at a different file to load instead of ~/.cabal/config?
Also, am I correct assuming that if any one of the configured repositories is unreachable, Cabal will fail the operation completely? Or does it depend on the operation (e.g., update vs. build)?
% cabal --help
Command line interface to the Haskell Cabal infrastructure.
....
Global flags:
-h --help Show this help text
-V --version Print version information
--numeric-version Print just the version number
--config-file=FILE Set an alternate location for the config
file
And, as I understand, if I do from the project directory cabal --config-file ~/.cabal/alt-config update, there's no need for cabal.project in that project dir to point at the alternate repository? Because the global ~/.cabal/alt-config file would contain it?
And, as I understand, if I do from the project directory
cabal --config-file ~/.cabal/alt-config update, there's no need forcabal.projectin that project dir to point at the alternate repository? Because the global~/.cabal/alt-configfile would contain it?
...affirmative :-) -- but you'll have to keep using that alternative config file consistently (i.e. keep passing it to your cabal build invocation as well)
...affirmative :-) -- but you'll have to keep using that alternative config file consistently
Yes, understood. Thank you!
It means that until there's a parameter in the project config or command-line to select which of the defined repositories should be considered active for this project - as a workaround I can use a second global config file, and the projects that need that other repo would just use --config-file ~/.cabal/alt-config in the command-line invocation.
Looking forward to when this is resolved via per-project cabal.project file content.
Thank you!
Most helpful comment
There are no currently way to specify which repositories are used. I.e. all are used,
~/.cabal/configandcabal.projectdata is combined.But it's quite top on my todo list, so I'm confident we'll have a way to specify the active repositories in
3.4. (We kind of need that for testing too).