Local name for source-repository-package?

[philderbeast]

With cabal sdist getting ghc-corroborate ready for upload to hackage, how do I include the source for ghc-tcplugins-extra from a renamed fork and how do I include cabal.project? Is hackage hermetic, can we only upload packages with the full set of dependencies already on hackage? So far the candidate package has uploaded without hackage complaining.

> tree
.
├── .gitmodules
├── cabal.project
├── ghc-corroborate
└── ghc-tcplugins-extra

# .gitmodules
[submodule "ghc-tcplugins-extra"]
  path = ghc-tcplugins-extra
  url = https://github.com/BlockScope/ghc-tcplugins-extra-undef.git

It looks like we can use non-hackage dependencies #2189 (also #5351). In this case I want avoid a dependency on hackage and use a fork of it.

I have a hunch I can alter the project file to make this happen but I can't follow the docs. If add source-repository-package to the project can I drop the git submodule?

In Specifying Packages from Remote Version Control Locations I cannot see a way to use a local name different to the repo name.

  -- cabal.project
  packages:
-     ghc-tcplugins-extra
      ghc-corroborate
+  source-repository-package
+     type: git
+     location: https://github.com/BlockScope/ghc-tcplugins-extra-undef
+     tag: 945e4a55f5f73f2a9d46188203930ed90d4185b6

Here's what I've tried by way of cabal sdist:

> cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library
> cabal help sdist
Generate a source distribution file (.tar.gz).

Usage: cabal sdist [FLAGS] [PACKAGES]

Generates tarballs of project packages suitable for upload to Hackage.

Flags for sdist:
 -h, --help                     Show this help text
 --project-file=FILE            Set the name of the cabal.project file to
                                search for in parent directories
 -z, --ignore-project           Ignore local project configuration
 -v, --verbose[=n]              Control verbosity (n is 0--3, default
                                verbosity level is 1)
 --builddir=DIR                 The directory where Cabal puts generated build
                                files (default dist)
 -l, --list-only                Just list the sources, do not make a tarball
 --null-sep                     Separate the source files with NUL bytes
                                rather than newlines.
 -o, --output-directory=PATH    Choose the output directory of this command.
                                '-' sends all output to stdout

> cabal sdist ghc-corroborate
Wrote tarball sdist to
/.../dist-newstyle/sdist/ghc-corroborate-0.1.0.tar.gz
>  cabal sdist ghc-corroborate --project-file=cabal.project
Wrote tarball sdist to
/.../dist-newstyle/sdist/ghc-corroborate-0.1.0.tar.gz
> cd ghc-corroborate
> cabal sdist ghc-corroborate --project-file=../cabal.project
cabal: The component library cannot be packaged for distribution on its own.
Only entire packages may be packaged for distribution.

I can't quite follow the last error message. Isn't ghc-corroborate a package as it has its own ghc-corroborate.cabal file?

The error phrasing of "component library" to refer to a component that is a library is confusing (can we not use the library's name in the error message?). I can report the manual doesn't mention "component library" but does mention "library component".

cabal/cabal-install/src/Distribution/Client/CmdSdist.hs

Lines 311 to 313 in c72b866

	renderTargetProblem (ComponentsNotAllowed cname) =
	"The component " ++ showComponentName cname ++ " cannot be packaged for distribution on its own. "
	++ "Only entire packages may be packaged for distribution."

[Mikolaj]

For the first question, add this to your .cabal file:

extra-doc-files: cabal.project

[phadej]

can we only upload packages with the full set of dependencies already on hackage?

You can upload packages without dependencies being on Hackage. It's not a good idea as the package will be unbuildable.

If I understand what you are trying to do, you could rename the fork of your dependency and upload it, if it's meant to be permanent solution.

Adding cabal.project to sdist is useless it won't be used by tools. (Think stack, Nix, etc. they don't care).

---

How do I include the source for ghc-tcplugins-extra from a renamed fork and how do I include cabal.project?

Another solution is to use internal libraries or just vendoring the sources as is. e.g. aeson "vendors" / bundles the contents of attoparsec-iso8601.

Keep it simple.

[philderbeast]

Thanks for the answers so far. I'd like to fill in some of the gaps in the docs around this if that's OK.

[Mikolaj]

Thanks for the answers so far. I'd like to fill in some of the gaps in the docs around this if that's OK.

Yes, please do!

[xsebek]

Could Cabal produce a warning when running cabal sdist about source-repository-package being ignored?

Seems like this could lead to errors when the CI uses cabal.project that points to bugfixes of other packages, but then the Hackage release does not use the other package with the fix.

[gbaz]

I think we can close this as the initial questions have been resolved.

[gbaz]

(with regards to "Could Cabal produce a warning when running cabal sdist about source-repository-package being ignored?" i don't think that would be a good approach. I've worked on plenty of packages that are both designed for sdist and also happen to have some pinned source-repository-package stuff specific to a local development or ci environment)