cabal freeze should take current cabal.config in the account

[gracjan]

Scenario:

1. Create my-package.cabal, add some dependenciens.
2. Freeze versions of dependencies with cabal freeze.
3. Add some more dependencies to my-package.cabal.
4. Use cabal freeze to fill in exact versions of new dependencies.

Expected:

In 4 cabal freeze fills in the missing information taking current cabal.config in account.

Current:

In 4 cabal freeze resolves packages from scratch producing a new list of package versions that is effectively random and has no relation to anything project related.

(Note about 'effectively random': resolved packages depend on last 'cabal update'. What 'cabal update' fetches is out of control and is a good source of entropy. Hence: random).

[23Skidoo]

/cc @benarmston

[benarmston]

When freeze was first written it was decided that it should always try to
update the frozen packages. That is it should ignore the cabal.config file.
I didn't like that behaviour but implemented it anyway. And without an
option to change it. My bad :-(

I think we should at least have an option to use the cabal.config file and
probably do so by default. We would also have to consider how this would
interact with preferring installed packages or not.
On 3 Apr 2015 13:07, "Mikhail Glushenkov" notifications@github.com wrote:

/cc @benarmston https://github.com/benarmston

—
Reply to this email directly or view it on GitHub
#2519 (comment).

[gracjan]

Currently cabal install --only-dep does version resolution. cabal configure also does version resolution, probably using some other mechanism. cabal freeze also does version resolution taking some of the data into account and skipping other sources.

Version resolution takes into account what is installed, mostly. Sometimes it takes selected compiler version in account. If it is not installed then guesses something somehow, hard to know. There are silent discrepancies between 'don't have a sandbox', 'have a sandbox' and 'have a sandbox with installed packages' and 'have a sandbox with installed packages for different compiler'.

Add also that cabal-install needs to be of large enough version to even look at cabal.config but you cannot put 'cabal-version: > 1.20' because this makes project silently depend on 'Cabal > 1.20' but it will not install 'Cabal > 1.20' and you are in deployment hell.

Also: 'it was decided': can you point me when and who 'decided it'?

[benarmston]

On 3 Apr 2015 14:35, "gracjan" notifications@github.com wrote:

Currently cabal install --only-dep does version resolution. cabal
configure also does version resolution. cabal freeze also does version
resolution taking some of the data into account and skipping other.

That's about right. There are multiple use cases for freeze and it
currently does a bad job for some (most?) of them. The hard part I think
is 1) identifying all of the use cases 2) figuring out a sane UI to
support them all and 3) finding time for all of this.

Version resolution takes into account what is installed. Sometimes takes
selected compiler version in account. If it is not installed then guesses
something somehow. There are silent discrepancies between 'don't have
'sandbox'', 'have sandbox' and 'have sandbox with installed packages'.

Could you explain these discrepancies better please?

Add also that cabal-install needs to be of large enough version to even
look at cabal.config but you cannot put 'cabal-version: > 1.20' because
this makes project silently depend on 'Cabal > 1.20' but will not install
'Cabal > 1.20' and you are in deployment hell.

I'm not sure I understand this point or at least not how it pertains to
freeze. Could you expand on it please?

Also: 'it was decided': can you point me when and who 'decided it'?

I can but it will have to be later. I'm on my phone at the moment and don't
want to try to trawl through github issues to find it.

—
Reply to this email directly or view it on GitHub.

[gracjan]

Could you explain these discrepancies better please?

I guess there are many. Example:

1. cabal sandbox init
2. cabal install --only-dep -w ghc-7.6.3
3. cabal configure -w ghc-7.6.3
4. cabal freeze

Expected:

cabal freeze freezes based on what is inside sandbox

Actual:

cabal freeze ignores what is inside sandbox because it uses different compiler than install/configure steps

Solution:

cabal freeze should refuse to work if information is missing, unless given a command line option. Then, if there is something strange happening, user will be notified and can opt in for the 'guessing' part. Current default to 'I'll just guess!' is nondeterministic, leads to frustration and silent errors.

[aslatter]

What happened to @gracjan burned me as well.

The example above is particularly frustrating because there is no -w option to freeze.

It caught me by surprise that cabal freeze re-invokes the solver - I'm not saying the original design was wrong, just not intuitive.

[grayjay]

Closing as a duplicate of #2265.