source-repository-package seems to be treated as local

[quasicomputational]

This means that --enable-tests will build the tests of those dependencies, --enable-benchmarks will build the benchmarks, new-test will (presumably) run their tests, and so on.

This was quite surprising to me, since my primary use case for source-repository-package is to swap in a broken version of a dependency with a fixed pre-release version from the VCS. But doing that means that, if the dependency's test suite is not in great condition (e.g., it doesn't even compile because I'm trying to port things to a new GHC version), I'm suddenly going to be affected by that!

The discussion in #2189 suggests that this is for implementation convenience (which is entirely reasonable), rather than a deliberate decision. Are there use cases where packages being pulled from a VCS should be local for principled reasons? I can't think of any off the top of my head, but there's a whole universe of potential weirdness out there.

Edit: Also, I suspect we could decouple the relevant aspects of 'localness': a source-repository-package could be treated as local for the purposes of recompilation checking and not going into the global store, but non-local for the purposes of 'should this package's tests/benchmarks be available for building/running?'.

[23Skidoo]

/cc @dcoutts @typedrat

[hvr]

Fwiw, I consider having source-repository-package cached in the global store a killer feature; and I feel like in the majority of use-cases you'd want to err on caching it globally rather than not. That being said, I welcome the ability to opt-out and force it to be treated as local if the user wishes so.

Something I think I briefly discussed with Duncan in the context of the source-repo-package UI was to have a generic uniform "package" syntax where you could explicitly force/control whether a package in the build-plan is demoted to a local package or not.

[typedrat]

How do packages that are in an index that is referenced in a specific cabal.project but is not globally available handled? Because honestly I think internally treating the source-repository-package as a source of packages rather than adding a new local package for it makes more sense.

[RyanGlScott]

What is the status of this ticket after #5708 was merged into cabal-install-2.4? I was originally redirected to this ticket after seeing #5612 (which I was directly affected by in haskell-CI/haskell-ci#186), and after upgrading to cabal-install-2.4, I can confirm that I am no longer affected by #5612. Since #5612 was closed as a duplicate of this ticket, does that mean this ticket is also fixed now?

[hvr]

@RyanGlScott this ticket is still relevant insofar as the source-repository-packages are still treated as if they were local packages whereas it's desirable instead to have the ability to treat them as non-local ones.

[harendra-kumar]

In a CI build --enables-tests starts building tests of a source-repository-package and sometimes the dependencies of tests even fail to build (for ghcjs in my current use case). Therefore, this issue is a must fix to enable the CI use case.

[hvr]

@harendra-kumar is this workaroundable by adding a package stanza matching the source-repository-package disabling the tests again? i.e. for a package foo pulled in via git,

package foo
  tests: False
  benchmarks: False

?

(if yes, maybe we can have this "hack" wired into cabal automatically, as a short-term workaround/quickfix )

[harendra-kumar]

@hvr this will work for me. I guess it makes sense to do it only if this is significantly easier/faster to do compared to the right long term fix.