Automatically install dependencies before building, if needed #1100

Open
tibbe opened this Issue Nov 6, 2012 · 12 comments

Comments

Projects
None yet
5 participants
Owner

tibbe commented Nov 6, 2012

If you're currently working on a package, the right way to build it is as follows:

cabal install --only-dependencies
cabal build

However, this is unintuitive and repetitive and many users end up using

cabal install

instead.

The reasons I've heard for not having build imply installing dependencies is that users might not want packages to be downloaded from the internet, unless they explicitly use cabal install. While that's a fair point, I think it should be an opt-out rather than an opt-in because:

  • Users will end up have to install the dependencies anyway and there's typical no other options than installing them from Hackage.
  • Many users use cabal install instead of cabal build, for the reasons given above, making it a moot point.

Once we start installing dependencies by default, the very first run of cabal build may take a long time, especially if sandboxing is used, so I think we should output the following message before installing dependencies:

"Installing dependencies. This may take a long time if this is the first time you build this package."

/cc @dcoutts @23Skidoo

@ghost ghost assigned 23Skidoo Nov 10, 2012

Member

23Skidoo commented Nov 17, 2012

If we decide to implement this idea, then I think it will make sense to also add back the --sandbox flag for configure which initialises and populates a sandbox in the current directory.

Owner

tibbe commented Nov 17, 2012

@23Skidoo I'm not sure I follow how these two are related. If the user has already created a sandbox using cabal sandbox init then the dependencies of the package would be installed into it by cabal build. If the user hasn't created a sandbox, then presumably the dependencies should be installed in the shared (user or global) package DB.

Member

23Skidoo commented Nov 17, 2012

@tibbe cabal configure fails if there are unmet dependencies, so automatically installing dependencies before building means doing it in configure. The reason we have a separate sandbox init is because we didn't want configure to download packages from the Internet. If we will allow that, then I think it's logical to bring back configure --sandbox to make it possible to initialise a sandbox, install all dependencies into it and configure the package in one step.

Owner

tibbe commented Nov 17, 2012

@23Skidoo We don't necessarily have to install dependencies in configure, even if we make installing dependencies the default. In fact I don't think we should. What I think we should do is to have cabal build be equivalent to

cabal build = cabal install --only-dependencies && cabal configure && cabal old-build

As you see above, the dependencies are not installed by configure. This lets people just type cabal build and have things just work, while still allowing people to run

cabal configure -fmy-flag
cabal build  # implies the long command line above

when they need to set some configure flags. Note that since the new cabal build calls configure, the -fmy-flag flag would still be used, as configure reads the settings from previous configure attempts from a file.

Member

23Skidoo commented Nov 17, 2012

What I think we should do is to have cabal build be equivalent to

cabal build = cabal install --only-dependencies && cabal configure && cabal old-build

Then we can make --sandbox a build flag, unless we decide to enable sandboxes by default, in which case we should have --no-sandbox.

Owner

tibbe commented Nov 17, 2012

I thought the UI we settled on was to explicitly manage the sandbox through cabal sandbox init/add-source/delete, to avoid confusing things like:

cabal build --sandbox
cabal build

In the above example, does the second cabal build use the sandbox? It should, but having a --sandbox flag on build makes that fact unclear. Having a sandbox is a property of the working directory, rather than a property of build, hence a separate cabal sandbox command to manage it.

Member

23Skidoo commented Nov 17, 2012

Having a sandbox is a property of the working directory, rather than a property of build, hence a separate cabal sandbox command to manage it.

Yes. I just think that having a --sandbox flag would be convenient. I'm not going to insist on adding it.

Owner

tibbe commented Nov 17, 2012

Yes. I just think that having a --sandbox flag would be convenient. I'm not going to insist on adding it.

I see. If you don't mind lets leave it out for now. We can always add it later.

Owner

tibbe commented Aug 26, 2013

Lets try to do this for 1.20

Collaborator

dalaing commented Jan 9, 2014

Under this scheme, should cabal configure create an install plan for missing dependencies so that people know about potential breakages sooner rather than later? Or would that complicate things too much?

Owner

tibbe commented Mar 5, 2014

OK. I think we should definitely have cabal configure imply cabal install --only-dependencies for sandboxes (which transitively means cabal build will also install dependencies and so forth.) Not having this implied means people still prefer cabal install to cabal build. Lets not do it outside sandboxes for now, as it might break users installs there.

@ttuegel ttuegel modified the milestones: cabal-install-1.24, cabal-install-1.22 Apr 23, 2015

@23Skidoo 23Skidoo modified the milestones: cabal-install 1.24, cabal-install 1.26 Feb 21, 2016

@ezyang ezyang modified the milestone: cabal-install 2.0 Sep 6, 2016

Contributor

ezyang commented Sep 11, 2016

nix-local-build does this.

@23Skidoo 23Skidoo removed their assignment Sep 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment