Re: Agreeing on a UI for sandboxes

newer
Hackage 2

older
Uploading imported package to...

Mikhail Glushenkov

31 Aug 2012 31 Aug '12

8:34 a.m.

Hi, On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell wrote:

...

Perhaps a separate command, cabal init-sandbox, would be the best approach. Running that command would create the right package environment for running in a sandbox and the remaining commands would then use that sandbox. Separating init-sandbox from configure prevents the user from removing the sandbox preference when reconfiguring for some other reason (e.g. to add --enable-tests). To get out of the sandbox the user would edit the package environment file.

One problem with a separate sandbox-init command is that it gives you two ways to specify configure flags. E.g. you can do $ cabal sandbox-init -w /path/to/compiler-1 $ cabal install --only-dependencies and then run $ cabal configure -w /path/to/compiler-2 which will rewrite the package environment file, but then fail due to dependencies not being installed (since we are now using a different compiler). It can also be a bit non-obvious that when you run 'configure' after 'sandbox-init' it uses the configure flags given to 'sandbox-init' earlier (saved in the package environment file).

...

...
I wouldn't change it yet. If at all, it should be a flag per add-source. Not everything you add-source are libraries you necessarily actively develop at the time. And I guess you can add-source not only local packages, right?

I'm worried about making cabal even more cumbersome to use. [...] If the use manually has to rebuild dependencies every time the change even when using a sandbox we have essentially no improvement over status quo and or cabal-dev.

We can make automatic updating of dependencies the default and current behaviour optional. In any case, we need to agree how to update dependencies automatically. A naive algorithm is to just reinstall everything (which is what cabal-dev does). We can try to be a bit smarter and do something like the following: For each dependency added with add-source: If the dependency has already been configured and there is no need to reconfigure: Either just run 'cabal build' and reinstall only if the produced lib/exe is newer than the one we have installed, or get a list of all source files for each target (is this possible?) and rebuild&reinstall only if there is some source file newer than the installed target. Otherwise just configure, build and install. Also, should this happen each time the user runs 'cabal build' or only when running 'cabal install'? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Show replies by date

Johan Tibell

31 Aug 31 Aug

2:25 p.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Fri, Aug 31, 2012 at 5:34 AM, Mikhail Glushenkov wrote:

...

Hi,

On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell wrote:

...
Perhaps a separate command, cabal init-sandbox, would be the best approach. Running that command would create the right package environment for running in a sandbox and the remaining commands would then use that sandbox. Separating init-sandbox from configure prevents the user from removing the sandbox preference when reconfiguring for some other reason (e.g. to add --enable-tests). To get out of the sandbox the user would edit the package environment file.

One problem with a separate sandbox-init command is that it gives you two ways to specify configure flags. E.g. you can do

$ cabal sandbox-init -w /path/to/compiler-1 $ cabal install --only-dependencies

and then run

$ cabal configure -w /path/to/compiler-2

which will rewrite the package environment file, but then fail due to dependencies not being installed (since we are now using a different compiler). It can also be a bit non-obvious that when you run 'configure' after 'sandbox-init' it uses the configure flags given to 'sandbox-init' earlier (saved in the package environment file).

Let's have sandbox-init not take any configure arguments. It should just mark that the current repo should use a sandbox until sandbox-delete is run.

...

...
...
I wouldn't change it yet. If at all, it should be a flag per add-source. Not everything you add-source are libraries you necessarily actively develop at the time. And I guess you can add-source not only local packages, right?

I'm worried about making cabal even more cumbersome to use. [...] If the use manually has to rebuild dependencies every time the change even when using a sandbox we have essentially no improvement over status quo and or cabal-dev.

We can make automatic updating of dependencies the default and current behaviour optional. In any case, we need to agree how to update dependencies automatically. A naive algorithm is to just reinstall everything (which is what cabal-dev does). We can try to be a bit smarter and do something like the following:

For each dependency added with add-source: If the dependency has already been configured and there is no need to reconfigure: Either just run 'cabal build' and reinstall only if the produced lib/exe is newer than the one we have installed, or get a list of all source files for each target (is this possible?) and rebuild&reinstall only if there is some source file newer than the installed target. Otherwise just configure, build and install.

Also, should this happen each time the user runs 'cabal build' or only when running 'cabal install'?

Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?). -- Johan

Mikhail Glushenkov

3:27 p.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Fri, Aug 31, 2012 at 8:25 PM, Johan Tibell wrote:

...

Let's have sandbox-init not take any configure arguments. It should just mark that the current repo should use a sandbox until sandbox-delete is run.

It'll still be a bit confusing: $ cabal sandbox-init $ cabal install --only-dependencies -w /path/to/compiler $ cabal configure # Uses configure flags given to install

...

Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?).

This is very easy to implement, but all packages depending on the reinstalled libraries will have to be relinked and reinstalled, which is not very fun. You can test this by running 'cabal-dev install Cabal/ cabal-install/' twice in the Cabal source dir. With a larger number of dependencies it'll be even more annoying. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Mikhail Glushenkov

4:13 p.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Fri, Aug 31, 2012 at 9:27 PM, Mikhail Glushenkov wrote:

...

...
Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?).

Additionally, if you edit the .cabal file of an add-source dependency and add new dependencies, they *will* have to be downloaded from the internet. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

5:45 p.m.

New subject: Agreeing on a UI for sandboxes

On Fri, Aug 31, 2012 at 1:13 PM, Mikhail Glushenkov wrote:

...

Hi,

On Fri, Aug 31, 2012 at 9:27 PM, Mikhail Glushenkov wrote:

...
...
Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?).

Additionally, if you edit the .cabal file of an add-source dependency and add new dependencies, they *will* have to be downloaded from the internet.

That's fine I think. It's like you added a dependency of the main library. The user will need to install that dependency by running cabal install --only-dependencies There's a question whether he/she would have to run that in the dir of the dependency or the dir of the main lib. -- Johan

Johan Tibell

5:43 p.m.

New subject: Agreeing on a UI for sandboxes

On Fri, Aug 31, 2012 at 12:27 PM, Mikhail Glushenkov wrote:

...

Hi,

On Fri, Aug 31, 2012 at 8:25 PM, Johan Tibell wrote:

...
Let's have sandbox-init not take any configure arguments. It should just mark that the current repo should use a sandbox until sandbox-delete is run.

It'll still be a bit confusing:

$ cabal sandbox-init $ cabal install --only-dependencies -w /path/to/compiler $ cabal configure # Uses configure flags given to install

Why does `cabal install` affect the saved configure flags? Does it do that today even if you don't use the new sandbox stuff?

...

...
Here's an idea: as a compromise we can have cabal build imply reb-building and installing only add-source dependencies. This means nothing has to be downloaded from the internet. Lets not worry about minimize rebuilding now. Just call build in each add-source repo and reinstall the library. GHC will already skip most of the rebuilding (but not the relinking?).

This is very easy to implement, but all packages depending on the reinstalled libraries will have to be relinked and reinstalled, which is not very fun. You can test this by running 'cabal-dev install Cabal/ cabal-install/' twice in the Cabal source dir. With a larger number of dependencies it'll be even more annoying.

Lets try to make it work first and then optimize it. If we don't make it work all that will mean is that the user will have to perform the steps manually (i.e. 'cd' to the dependency directory, run build, 'cd' to the main directory, run install). -- Johan

Mikhail Glushenkov

1 Sep 1 Sep

6:11 a.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Fri, Aug 31, 2012 at 11:43 PM, Johan Tibell wrote:

...

Why does `cabal install` affect the saved configure flags? Does it do that today even if you don't use the new sandbox stuff?

It doesn't have to affect the package environment file, but otherwise you'll need to specify the configure flags twice: $ cabal sandbox-init $ cabal install --only-dependencies -w /path/to/compiler $ cabal configure -w /path/to/compiler # Fails without -w

...

Lets try to make it work first and then optimize it. If we don't make it work all that will mean is that the user will have to perform the steps manually (i.e. 'cd' to the dependency directory, run build, 'cd' to the main directory, run install).

OK.

...

That's fine I think. It's like you added a dependency of the main library. The user will need to install that dependency by running

cabal install --only-dependencies

There's a question whether he/she would have to run that in the dir of the dependency or the dir of the main lib.

The simple implementation is to make 'cabal build' imply 'cabal install' for all add-source dependencies. This will download and install all newly-added dependencies. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

2 Sep 2 Sep

8:04 p.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Sat, Sep 1, 2012 at 3:11 AM, Mikhail Glushenkov wrote:

...

On Fri, Aug 31, 2012 at 11:43 PM, Johan Tibell wrote:

...
Why does `cabal install` affect the saved configure flags? Does it do that today even if you don't use the new sandbox stuff?

It doesn't have to affect the package environment file, but otherwise you'll need to specify the configure flags twice:

$ cabal sandbox-init $ cabal install --only-dependencies -w /path/to/compiler $ cabal configure -w /path/to/compiler # Fails without -w

I see. This is no worse (or better) than the current situation today. I think the real solution here is to get rid of a separate "install the obviously needed dependencies"-step. Since I think we need to discuss such a change more in depth, I suggest we just leave the sandboxes having to repeat the -w flag twice, just like non-sandboxes already have to. In general lets just have sandboxes behave exactly as non-sandbox builds, with the exception of the separate package DB and rebuilding add-source deps, for now. This will get something useful into users' hands quicker.

...

...
That's fine I think. It's like you added a dependency of the main library. The user will need to install that dependency by running

cabal install --only-dependencies

There's a question whether he/she would have to run that in the dir of the dependency or the dir of the main lib.

The simple implementation is to make 'cabal build' imply 'cabal install' for all add-source dependencies. This will download and install all newly-added dependencies.

Andres might protest that this again would imply installing stuff from the Internet. Lets have it instead imply `configure && cabal build` and registering in the sandbox package DB for now. We'll revisit automatic installation later. -- Johan

Mikhail Glushenkov

3 Sep 3 Sep

5:24 a.m.

New subject: Agreeing on a UI for sandboxes

Hi Johan, On Mon, Sep 3, 2012 at 2:04 AM, Johan Tibell wrote:

...

In general lets just have sandboxes behave exactly as non-sandbox builds, with the exception of the separate package DB and rebuilding add-source deps, for now. This will get something useful into users' hands quicker.

OK. If we decide to make sandbox-init install the dependencies, it'll have to accept configure flags.

...

Andres might protest that this again would imply installing stuff from the Internet. Lets have it instead imply `configure && cabal build` and registering in the sandbox package DB for now. We'll revisit automatic installation later.

This can be done, but will be a bit more involved. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

12:10 p.m.

New subject: Agreeing on a UI for sandboxes

On Mon, Sep 3, 2012 at 2:24 AM, Mikhail Glushenkov wrote:

...

OK. If we decide to make sandbox-init install the dependencies, it'll have to accept configure flags.

That's true. However, I don't think we should install dependencies at sandbox initialization time, but at build time and hence build will have to take configure flags. But lets leave it alone for now and deal with automatically installing dependencies in some future step.

...

...
Andres might protest that this again would imply installing stuff from the Internet. Lets have it instead imply `configure && cabal build` and registering in the sandbox package DB for now. We'll revisit automatic installation later.

This can be done, but will be a bit more involved.

What are the main difficulties compared to calling install? -- Johan

Mikhail Glushenkov

3:50 p.m.

New subject: Agreeing on a UI for sandboxes

Hi Johan, On Mon, Sep 3, 2012 at 6:10 PM, Johan Tibell wrote:

...

That's true. However, I don't think we should install dependencies at sandbox initialization time, but at build time and hence build will have to take configure flags.

Sure, this would work fine too.

...

...
...
Andres might protest that this again would imply installing stuff from the Internet. Lets have it instead imply `configure && cabal build` and registering in the sandbox package DB for now. We'll revisit automatic installation later.

This can be done, but will be a bit more involved.

What are the main difficulties compared to calling install?

-It's just that I had a version using install already working. It'll take me a bit more time to make it use configure/build/register instead. I'm a bit busy right now, so this will have to wait until next week. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

6:52 p.m.

New subject: Agreeing on a UI for sandboxes

On Mon, Sep 3, 2012 at 12:50 PM, Mikhail Glushenkov wrote:

...

-It's just that I had a version using install already working. It'll take me a bit more time to make it use configure/build/register instead. I'm a bit busy right now, so this will have to wait until next week.

No problem. There's no rush.

Mikhail Glushenkov

4 Sep 4 Sep

5:17 p.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Tue, Sep 4, 2012 at 12:52 AM, Johan Tibell wrote:

...

On Mon, Sep 3, 2012 at 12:50 PM, Mikhail Glushenkov wrote:

...
-It's just that I had a version using install already working. It'll take me a bit more time to make it use configure/build/register instead. I'm a bit busy right now, so this will have to wait until next week.

No problem. There's no rush.

I looked more closely into this, and it seems like the easiest solution is a --no-download flag for "install". It can be implemented either by exiting with error if the install plan contains packages that aren't already installed (forcing the user to run "install --only-dependencies") or by somehow coaxing the constraint solver into rejecting such packages (is this possible?). -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

6:38 p.m.

New subject: Agreeing on a UI for sandboxes

On Tue, Sep 4, 2012 at 2:17 PM, Mikhail Glushenkov wrote:

...

I looked more closely into this, and it seems like the easiest solution is a --no-download flag for "install". It can be implemented either by exiting with error if the install plan contains packages that aren't already installed (forcing the user to run "install --only-dependencies") or by somehow coaxing the constraint solver into rejecting such packages (is this possible?).

Would that be equivalent of configure && build && registering or are there some subtle differences. I'm worried that if there are builds my fail for confusing reasons. -- Johan

Mikhail Glushenkov

8:56 p.m.

New subject: Agreeing on a UI for sandboxes

Hi, On Wed, Sep 5, 2012 at 12:38 AM, Johan Tibell wrote:

...

On Tue, Sep 4, 2012 at 2:17 PM, Mikhail Glushenkov wrote:

...
I looked more closely into this, and it seems like the easiest solution is a --no-download flag for "install". It can be implemented either by exiting with error if the install plan contains packages that aren't already installed (forcing the user to run "install --only-dependencies") or by somehow coaxing the constraint solver into rejecting such packages (is this possible?).

Would that be equivalent of configure && build && registering or are there some subtle differences. I'm worried that if there are builds my fail for confusing reasons.

Yes, it should be. The reason I want to use "install" is that the sandbox can contain reverse dependencies of the add-source packages which need to be updated when the add-source packages are rebuilt. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4640

Age (days ago)

4645

Last active (days ago)

List overview

Download

14 comments

2 participants

participants (2)

Johan Tibell
Mikhail Glushenkov