Skip to content

Behaviour of postCopy and postInstall hook is confusing #709

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

Open
bos opened this issue May 24, 2012 · 3 comments
Open

Behaviour of postCopy and postInstall hook is confusing #709

bos opened this issue May 24, 2012 · 3 comments

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #718, reported by guest on 2010-07-24)

While working on the Bluetile cabal package ( http://hackage.haskell.org/package/bluetile ) I used Cabal's hook system to install executables to the libexec directory.

It took me a while to figure out that the postCopy hook is the only hook to run when you invoke 'cabal copy' and the postInstall hook is the only hook to run when you invoke 'cabal install'.

This is both confusing and unfortunate.
Since the Cabal documentation elsewhere states that 'cabal install' is just "register + copy" one would assume that upon 'cabal install' the postCopy hook runs as well.

Now I had to write two hooks, both for postCopy and for postInstall, to make it work for users that run 'cabal install' as well as cases where 'cabal copy' is used (for example by distributions, while preparing their packages).

This can probably not be fixed without breaking a bunch of Cabal packages, so maybe some kind of warning or big note in the documentation would help in the meantime.

Best regards!
Jan

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2010-07-24)

Yes it's pretty crazy and confusing. I'm not sure we can change it easily however as I think it would break old packages (that's why we'd not done it already).

Though perhaps someone could look at how a smooth transition might work.

Alternatively we have to wait for a full redesign of the hooks interface.

@gregorycollins
Copy link
Member

Closing as wontfix. As Duncan pointed out, we can't change the behaviour without redesigning the hooks altogether, and given the other 500 bugs on the tracker I don't think there's enough friction for anyone to ever get to this.

@sheaf
Copy link
Collaborator

sheaf commented Oct 5, 2023

Re-opening to ensure this is taken into account in the design of the new Hooks build-type (see #9292).

@dcoutts dcoutts reopened this Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants