-
Notifications
You must be signed in to change notification settings - Fork 710
Bundle Cabal and Cabal-syntax source with cabal-install? #9741
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
Comments
Adding a complicated and unprecedented (nobody else does something like this, right?) path that can only be triggered in unusual circumstances seems like a recipe for trouble, IMO. |
To me it doesn't seem worth the trouble, since normal releases are not affected |
The issue only seems to arise when using pre-release versions of cabal, no? In such cases, I think its fine that they are not fully feature-complete until release, or that we require user making use of them require a custom repo. I do think that a custom remote repo url for the bleeding edge of Cabal would be nice to provide, to facilitate pre-release testing, and this should be straightforward to add to existing github infrastructure? We could then document this as a suggested |
👎 cabal-install already supports building a specific version of Cabal for a package custom-setup. Using source-repository-package to include Cabal's master is the correct solution I think. edit: does source-repository-package add an available version or overrides the package? 🤔 |
I didn't check whether a git diff
diff --git a/cabal.project b/cabal.project
index d506fe9b1..4773934a0 100644
--- a/cabal.project
+++ b/cabal.project
@@ -1,6 +1,11 @@
import: cabal.project.latest-ghc
-packages: Cabal/
+source-repository-package
+ type: git
+ location: .
+ branch: master
+ subdir: Cabal
+
packages: cabal-testsuite/
packages: Cabal-syntax/
packages: cabal-install/
|
I tried a little harder with
|
@philderbeast that's interesting but what is the problem you are trying to solve? Why using |
@andreabedini I don't have a problem with |
That quote was indeed the context I had missed <3 thank you |
Perhaps we should bundle the latest
Cabal
andCabal-syntax
libraries with thecabal-install
executable data files.Then
cabal-install
can decide whether to build the latestCabal
library on the fly if the user's plan requires a `very new cabal version.For example #9632 would benefit from this, if you use
--multi-repl
you get a constraint on a very newCabal
l library.Some care would need to be taken to engineer things so that the new version is not picked as a matter of priority and only if explicitly needed.
My intuition is that if the packages were provided as a local+noindex repo then things would work out "just right".
I constructed an incomplete POC here (not currently using local+noindex): https://github.com/mpickering/cabal/tree/wip/bundle-cabal-package
Is this desirable to keep working on?
The text was updated successfully, but these errors were encountered: