-
Notifications
You must be signed in to change notification settings - Fork 696
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
WIP: Redesign cabal {upload,haddock,check,sdist}
to provide a better Cabal/Hackage UX
#3837
Comments
Sure why not. I don't upload sdists all that often so I can't assess if this fills a need. |
@hvr when are you aiming this for? I guess not 2.0? How about 2.2? |
@ezyang yeah, 2.2 is more realistic; it'd be useful to have more pieces working (new-test/new-haddock) before tackling this one; and also to combine this with tge switch to new-build as default |
I'm unmilestoning this. The design will arrive when it will arrive. We have bumping this since 2.2. |
This ticket is here to remind me to write down a new workflow design involving the commands
cabal sdist
cabal check
cabal haddock
cabal upload
and their interactions to make it more convenient for users, as well as improve quality of Hackage uploads a bit.
The basic gist is that
cabal upload
shall provide a convenient way to perform (more or less) the following sequence of commands (andsdist
/check
/haddock
should be augmented consistently):cabal sdist
chdir(2)
to itecho 'packages: .' > cabal.project
cabal new-build
cabal new-test
cabal new-benchmark
cabal new-haddock --for-hackage
cabal upload $OLDPWD/dist/$SRCTAR
cabal upload -d dist/$DOCTAR
This all without sacrificing control over the individual phases if the user needs it.
/cc @glguy who suggested something like this to me
The text was updated successfully, but these errors were encountered: