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

Finish new-install #5399

Merged
merged 39 commits into from Jul 13, 2018

Conversation

@typedrat
Collaborator

typedrat commented Jun 26, 2018

Closes #4558.

Adds support for:

  • Local targets
  • Libraries

--

Please include the following checklist in your PR:

  • Patches conform to the coding conventions.
  • Any changes that could be relevant to users have been recorded in the changelog.
  • The documentation has been updated, if necessary.
  • If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

@typedrat typedrat self-assigned this Jun 26, 2018

@typedrat typedrat requested review from 23Skidoo and hvr Jun 26, 2018

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jun 27, 2018

Collaborator

Okay, so this is now feature-complete in the loosest sense.

The following cases still need to be handled:

  • Tell the user when environment files aren't supported (and therefore libraries can't be installed)
  • Quit out early when it will be a no-op.
  • Make the local package requirements not included when they aren't relevant
  • Fix bugs
  • Document
Collaborator

typedrat commented Jun 27, 2018

Okay, so this is now feature-complete in the loosest sense.

The following cases still need to be handled:

  • Tell the user when environment files aren't supported (and therefore libraries can't be installed)
  • Quit out early when it will be a no-op.
  • Make the local package requirements not included when they aren't relevant
  • Fix bugs
  • Document
go :: UnitId -> [(ComponentTarget, [TargetSelector])] -> [GhcEnvironmentFileEntry]
go unitId targets
| any hasLib targets = [GhcEnvFilePackageId unitId]

This comment has been minimized.

@typedrat

typedrat Jul 2, 2018

Collaborator
❯ cat ~/.ghc/x86_64-darwin-8.4.2/environments/default
package-id lnr-1.20.7-359f8114

That's what I get after I try to install linear. Why do I not get the vowels?

@typedrat

typedrat Jul 2, 2018

Collaborator
❯ cat ~/.ghc/x86_64-darwin-8.4.2/environments/default
package-id lnr-1.20.7-359f8114

That's what I get after I try to install linear. Why do I not get the vowels?

This comment has been minimized.

@fgaz

fgaz Jul 2, 2018

Collaborator

This comment has been minimized.

@typedrat

typedrat Jul 2, 2018

Collaborator

Hmm, how would I get around that...

@typedrat

typedrat Jul 2, 2018

Collaborator

Hmm, how would I get around that...

@alexbiehl

This comment has been minimized.

Show comment
Hide comment
@alexbiehl

alexbiehl Jul 3, 2018

Member

Awww I fucked up the merge with the Github online editor! Sorry about that!

Member

alexbiehl commented Jul 3, 2018

Awww I fucked up the merge with the Github online editor! Sorry about that!

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Jul 3, 2018

Member

Just rebase.

Member

23Skidoo commented Jul 3, 2018

Just rebase.

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 6, 2018

Collaborator

Should be done, at least done enough to get smacked around by other people. It works for me™ but I haven't had time/access to machines to test it on anything but macOS.

Collaborator

typedrat commented Jul 6, 2018

Should be done, at least done enough to get smacked around by other people. It works for me™ but I haven't had time/access to machines to test it on anything but macOS.

@typedrat typedrat changed the title from [WIP] Finish new-install to Finish new-install Jul 6, 2018

@typedrat typedrat added this to the 2.4 milestone Jul 7, 2018

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 7, 2018

Collaborator

7.4 is legitimately broken, but it's also outside of our support window.

Collaborator

typedrat commented Jul 7, 2018

7.4 is legitimately broken, but it's also outside of our support window.

@quasicomputational

This comment has been minimized.

Show comment
Hide comment
@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

It's not working for me:

$ cabal new-run cabal -- -v2 new-install lib:Cabal
Resolving dependencies...
Up to date
Reading available packages of hackage.haskell.org...
Using most recent state specified from most recent cabal update
index-state(hackage.haskell.org) = 2018-07-02T15:20:16Z
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/Cabal-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-testsuite-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-install-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/solver-benchmarks-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/pretty-show-1.6.16.tar.gz
Resolving dependencies...
/home/sam2/.local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /home/sam2/.local/bin
found ghc-pkg in /home/sam2/.local/bin/ghc-pkg
/home/sam2/.local/bin/ghc-pkg --version
/home/sam2/.local/bin/ghc --supported-languages
/home/sam2/.local/bin/ghc --info
Distribution/Simple/GHC.hs:453:5-53: Irrefutable pattern failed for pattern Just ghcProg

That GHC it's trying to use is 8.4.2.

Collaborator

quasicomputational commented Jul 7, 2018

It's not working for me:

$ cabal new-run cabal -- -v2 new-install lib:Cabal
Resolving dependencies...
Up to date
Reading available packages of hackage.haskell.org...
Using most recent state specified from most recent cabal update
index-state(hackage.haskell.org) = 2018-07-02T15:20:16Z
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/Cabal-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-testsuite-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-install-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/solver-benchmarks-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/pretty-show-1.6.16.tar.gz
Resolving dependencies...
/home/sam2/.local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /home/sam2/.local/bin
found ghc-pkg in /home/sam2/.local/bin/ghc-pkg
/home/sam2/.local/bin/ghc-pkg --version
/home/sam2/.local/bin/ghc --supported-languages
/home/sam2/.local/bin/ghc --info
Distribution/Simple/GHC.hs:453:5-53: Irrefutable pattern failed for pattern Just ghcProg

That GHC it's trying to use is 8.4.2.

@quasicomputational

Haven't been able to actually try the command out yet, but here are some notes from looking at the source.

{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE RecordWildCards #-}
module Distribution.Simple.GHC.EnvironmentParser

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

GHC has code for parsing these files in DynFlags, but this code is better and we should have an eye on reusing it in GHC. Specifically, I think exporting parseEnvironmentFile along with GhcEnvironmentFileEntry and its constructors from a non-internal module ought to be enough (which we ought to do anyway, since it's mentioned in the types of this non-internal module).

@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

GHC has code for parsing these files in DynFlags, but this code is better and we should have an eye on reusing it in GHC. Specifically, I think exporting parseEnvironmentFile along with GhcEnvironmentFileEntry and its constructors from a non-internal module ought to be enough (which we ought to do anyway, since it's mentioned in the types of this non-internal module).

This comment has been minimized.

@typedrat

typedrat Jul 9, 2018

Collaborator

Already exposed in Distribution.Simple.GHC. When we get this merged and available to GHC, I'd be happy to write a patch to use this instead. :)

@typedrat

typedrat Jul 9, 2018

Collaborator

Already exposed in Distribution.Simple.GHC. When we get this merged and available to GHC, I'd be happy to write a patch to use this instead. :)

Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
@@ -130,27 +172,188 @@ installAction (configFlags, configExFlags, installFlags, haddockFlags)
die' verbosity $ "--enable-benchmarks was specified, but benchmarks can't "
++ "be enabled in a remote package"
-- We need a place to put a temporary dist directory
let

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

In GitHub's infinite wisdom I can't attach review comments to lines that aren't changed, but there's a comment above with some TODOs. Those are solved now, right?

@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

In GitHub's infinite wisdom I can't attach review comments to lines that aren't changed, but there's a comment above with some TODOs. Those are solved now, right?

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018

Collaborator

Yep.

@typedrat

typedrat Jul 7, 2018

Collaborator

Yep.

Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
Show outdated Hide outdated Cabal/doc/nix-local-build.rst
Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
Show outdated Hide outdated cabal-install/Distribution/Client/CmdInstall.hs
@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 7, 2018

Collaborator

Should have fixed your issue, @quasicomputational.

Collaborator

typedrat commented Jul 7, 2018

Should have fixed your issue, @quasicomputational.

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 7, 2018

Collaborator

Why is there a parse error only on 7.10?

Collaborator

typedrat commented Jul 7, 2018

Why is there a parse error only on 7.10?

@quasicomputational

This comment has been minimized.

Show comment
Hide comment
@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

Sadly not, still happening with 0b2817f (this PR's latest commit).

Collaborator

quasicomputational commented Jul 7, 2018

Sadly not, still happening with 0b2817f (this PR's latest commit).

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 7, 2018

Collaborator

For some reason, it doesn't have your compiler in the program db it passes to getInstalledPackages.

Collaborator

typedrat commented Jul 7, 2018

For some reason, it doesn't have your compiler in the program db it passes to getInstalledPackages.

@quasicomputational

This comment has been minimized.

Show comment
Hide comment
@quasicomputational

quasicomputational Jul 7, 2018

Collaborator

No clue here, sorry. I can provide diagnostics if you've got any idea what might be helpful, or any new logging you put in to try and work out what's going on.

Collaborator

quasicomputational commented Jul 7, 2018

No clue here, sorry. I can provide diagnostics if you've got any idea what might be helpful, or any new logging you put in to try and work out what's going on.

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 7, 2018

Collaborator

I'll work on it more seriously after breakfast. 😝

Collaborator

typedrat commented Jul 7, 2018

I'll work on it more seriously after breakfast. 😝

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 7, 2018

Collaborator
    print progDb

on line CmdInstall.hs:319 would be helpful.

Collaborator

typedrat commented Jul 7, 2018

    print progDb

on line CmdInstall.hs:319 would be helpful.

@quasicomputational

This comment has been minimized.

Show comment
Hide comment
@quasicomputational

quasicomputational Jul 7, 2018

Collaborator
$ cabal new-run cabal -- new-install -v2 lib:Cabal
Resolving dependencies...
Up to date
Reading available packages of hackage.haskell.org...
Using most recent state specified from most recent cabal update
index-state(hackage.haskell.org) = 2018-07-07T12:53:49Z
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/Cabal-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-testsuite-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-install-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/solver-benchmarks-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/pretty-show-1.6.16.tar.gz
Resolving dependencies...
[]
/home/sam2/.local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /home/sam2/.local/bin
found ghc-pkg in /home/sam2/.local/bin/ghc-pkg
/home/sam2/.local/bin/ghc-pkg --version
/home/sam2/.local/bin/ghc --supported-languages
/home/sam2/.local/bin/ghc --info
Distribution/Simple/GHC.hs:453:5-53: Irrefutable pattern failed for pattern Just ghcProg
Collaborator

quasicomputational commented Jul 7, 2018

$ cabal new-run cabal -- new-install -v2 lib:Cabal
Resolving dependencies...
Up to date
Reading available packages of hackage.haskell.org...
Using most recent state specified from most recent cabal update
index-state(hackage.haskell.org) = 2018-07-07T12:53:49Z
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/Cabal-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-testsuite-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-install-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/solver-benchmarks-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/pretty-show-1.6.16.tar.gz
Resolving dependencies...
[]
/home/sam2/.local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /home/sam2/.local/bin
found ghc-pkg in /home/sam2/.local/bin/ghc-pkg
/home/sam2/.local/bin/ghc-pkg --version
/home/sam2/.local/bin/ghc --supported-languages
/home/sam2/.local/bin/ghc --info
Distribution/Simple/GHC.hs:453:5-53: Irrefutable pattern failed for pattern Just ghcProg
@quasicomputational

This comment has been minimized.

Show comment
Hide comment
@quasicomputational

quasicomputational Jul 10, 2018

Collaborator

Another minor docs thing: new-install is mentioned as unimplemented under "Where are my build products?", but that's not true any more! We need another example there.

Collaborator

quasicomputational commented Jul 10, 2018

Another minor docs thing: new-install is mentioned as unimplemented under "Where are my build products?", but that's not true any more! We need another example there.

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 10, 2018

Collaborator

@quasicomputational, you should be able to install package-ids as goals, that just slipped my mind.

Collaborator

typedrat commented Jul 10, 2018

@quasicomputational, you should be able to install package-ids as goals, that just slipped my mind.

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 10, 2018

Collaborator

@tom-bop, it's the sum of existing libraries (new-install a followed by new-install b gives you most of the bundled libraries, a, and b)

Collaborator

typedrat commented Jul 10, 2018

@tom-bop, it's the sum of existing libraries (new-install a followed by new-install b gives you most of the bundled libraries, a, and b)

@tom-bop

This comment has been minimized.

Show comment
Hide comment
@tom-bop

tom-bop Jul 10, 2018

@typedrat 👍 , but it won't for example have any of the package you "old-installed", right?

tom-bop commented Jul 10, 2018

@typedrat 👍 , but it won't for example have any of the package you "old-installed", right?

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 10, 2018

Collaborator

@tom-bop, that's correct.

Collaborator

typedrat commented Jul 10, 2018

@tom-bop, that's correct.

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Jul 11, 2018

Collaborator

I've been very tempted to introduce a different sub-command altogether for managing package environments, as the install name is a bit misleading at this point, as w/ a nix-style store, the term "installing" is not the proper mental model to have anymore IMO.

This is a good question. Whether or not we do it, it would be good to bikeshed what the "right" name might be, for conceptual clarity if nothing else. I was thinking "provide"?

Collaborator

gbaz commented Jul 11, 2018

I've been very tempted to introduce a different sub-command altogether for managing package environments, as the install name is a bit misleading at this point, as w/ a nix-style store, the term "installing" is not the proper mental model to have anymore IMO.

This is a good question. Whether or not we do it, it would be good to bikeshed what the "right" name might be, for conceptual clarity if nothing else. I was thinking "provide"?

@fgaz

This comment has been minimized.

Show comment
Hide comment
@fgaz

fgaz Jul 11, 2018

Collaborator

Or env, like nix

Collaborator

fgaz commented Jul 11, 2018

Or env, like nix

@andreabedini

This comment has been minimized.

Show comment
Hide comment
@andreabedini

andreabedini Jul 11, 2018

I landed here wondering why cabal new-install brittany fails (see conversation linked above and #5427).

While I am sure I don't fully understand the discussion, there's one important point I haven't seen mentioned. So here's my drive-by comment.

even when 3.0 lands, there will still be heaps of references on the internet to cabal install. Please don't break those! Beginners learn from Google and Stack Overflow, not from GitHub issues (like me :P). I would guess (but I have no data) that most of the references to cabal install are used in the context of installing a executable.

I've been very tempted to introduce a different sub-command altogether for managing package environments, as the install name is a bit misleading at this point, as w/ a nix-style store, the term "installing" is not the proper mental model to have anymore IMO.

I'd say go for it then. cabal install can emit a warning mentioning the new command.

Thanks.

andreabedini commented Jul 11, 2018

I landed here wondering why cabal new-install brittany fails (see conversation linked above and #5427).

While I am sure I don't fully understand the discussion, there's one important point I haven't seen mentioned. So here's my drive-by comment.

even when 3.0 lands, there will still be heaps of references on the internet to cabal install. Please don't break those! Beginners learn from Google and Stack Overflow, not from GitHub issues (like me :P). I would guess (but I have no data) that most of the references to cabal install are used in the context of installing a executable.

I've been very tempted to introduce a different sub-command altogether for managing package environments, as the install name is a bit misleading at this point, as w/ a nix-style store, the term "installing" is not the proper mental model to have anymore IMO.

I'd say go for it then. cabal install can emit a warning mentioning the new command.

Thanks.

@andreabedini andreabedini referenced this pull request Jul 11, 2018

Merged

Musical chairs to switch `new-` and `old-` #5358

4 of 4 tasks complete
@ekmett

This comment has been minimized.

Show comment
Hide comment
@ekmett

ekmett Jul 11, 2018

Member

If we're going to add v1-build, etc. we should add v2-build, etc. at the same time referencing the current new- behavior, so as to preemptively give people a forward-compat-friendly way to refer to the new build system. This would allow users who have lots of build scripts to skip one migration step, easing the transition, and ensuring that any similar changes in the future have a simple, clean, already-in-place migration plan.

Member

ekmett commented Jul 11, 2018

If we're going to add v1-build, etc. we should add v2-build, etc. at the same time referencing the current new- behavior, so as to preemptively give people a forward-compat-friendly way to refer to the new build system. This would allow users who have lots of build scripts to skip one migration step, easing the transition, and ensuring that any similar changes in the future have a simple, clean, already-in-place migration plan.

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 11, 2018

Collaborator

@ekmett, it's less trivial than it seems to add aliases, and I feel like the likelihood of a third new paradigm is low enough to not merit the work to add them for new- commands.

Collaborator

typedrat commented Jul 11, 2018

@ekmett, it's less trivial than it seems to add aliases, and I feel like the likelihood of a third new paradigm is low enough to not merit the work to add them for new- commands.

@ekmett

This comment has been minimized.

Show comment
Hide comment
@ekmett

ekmett Jul 11, 2018

Member

Then I don't particularly look forward to enduring all the same complaints when we get around to a v3. ;)

Member

ekmett commented Jul 11, 2018

Then I don't particularly look forward to enduring all the same complaints when we get around to a v3. ;)

@typedrat

This comment has been minimized.

Show comment
Hide comment
@typedrat

typedrat Jul 12, 2018

Collaborator

Y'know what, it's not as bad as I thought, but that'd be a different PR. :)

Collaborator

typedrat commented Jul 12, 2018

Y'know what, it's not as bad as I thought, but that'd be a different PR. :)

@typedrat typedrat referenced this pull request Jul 12, 2018

Merged

Add future-proof aliases for new- commands #5429

3 of 3 tasks complete
@hvr

This comment has been minimized.

Show comment
Hide comment
@hvr

hvr Jul 12, 2018

Member

@ekmett Well, my idea was rather to consider new- as such a v2- prefix, as that's what all the scripting out there has been using for 2-3 years (it's been in cabal-1.24, cabal-2.0 and cabal-2.2); introducing an additional v2- prefix alias now seems uneconomical to me. And in the hopefully unlikely event we ever need another UI generation, we'd just call it v3- (i.e. we do not call it new- as new- shall keep referring to the 2nd gen). IOW, the prefixes would be

  • v1-* refer to the 1st generation (supported since (yet unreleased) cabal-2.2.1.0)
  • new-* refer to the 2nd generation (supported since cabal-1.24)
  • v3-* for a future 3rd generation
Member

hvr commented Jul 12, 2018

@ekmett Well, my idea was rather to consider new- as such a v2- prefix, as that's what all the scripting out there has been using for 2-3 years (it's been in cabal-1.24, cabal-2.0 and cabal-2.2); introducing an additional v2- prefix alias now seems uneconomical to me. And in the hopefully unlikely event we ever need another UI generation, we'd just call it v3- (i.e. we do not call it new- as new- shall keep referring to the 2nd gen). IOW, the prefixes would be

  • v1-* refer to the 1st generation (supported since (yet unreleased) cabal-2.2.1.0)
  • new-* refer to the 2nd generation (supported since cabal-1.24)
  • v3-* for a future 3rd generation
@ekmett

This comment has been minimized.

Show comment
Hide comment
@ekmett

ekmett Jul 13, 2018

Member

@hvr You have to admit that state of affairs seems messy and inconsistent, especially in the event we ever do ship a v3-, no matter how its usage evolves.

At some unknown future point we may or may not get around to a v3-, and it may or may not want to take the new- monicker as it rolls out.

But in any of those worlds, having v2- would give a way to get current new-build style behavior in a stable way that will last through any v3- attempt, no matter if it chooses to take over new- or not. And in avoids the pretty awful inconsistency of new- referring to rather old behavior and of having every version but v2- be consistently named.

What I'd ideally want is to be able to make one change to my build scripts to migrate to v2- behavior after the next cabal release, and not to have to stir again until long after some future v3- comes along and I decide to move. While your v1-, new-, v3- story delivers on that, it does so in a way that ensures that new- is forever tainted to mean the current behavior rather than considering that future maintainers of cabal might prefer for it to switch to rolling forward, and requires folks to eventually know that new- really means old-but-not-that-old-.

Member

ekmett commented Jul 13, 2018

@hvr You have to admit that state of affairs seems messy and inconsistent, especially in the event we ever do ship a v3-, no matter how its usage evolves.

At some unknown future point we may or may not get around to a v3-, and it may or may not want to take the new- monicker as it rolls out.

But in any of those worlds, having v2- would give a way to get current new-build style behavior in a stable way that will last through any v3- attempt, no matter if it chooses to take over new- or not. And in avoids the pretty awful inconsistency of new- referring to rather old behavior and of having every version but v2- be consistently named.

What I'd ideally want is to be able to make one change to my build scripts to migrate to v2- behavior after the next cabal release, and not to have to stir again until long after some future v3- comes along and I decide to move. While your v1-, new-, v3- story delivers on that, it does so in a way that ensures that new- is forever tainted to mean the current behavior rather than considering that future maintainers of cabal might prefer for it to switch to rolling forward, and requires folks to eventually know that new- really means old-but-not-that-old-.

@hvr

This comment has been minimized.

Show comment
Hide comment
@hvr

hvr Jul 13, 2018

Member

@ekmett yes, in hindsight, having used new-* at all was probably not ideal. We should have used v2- right-away; but now we're faced with the choice whether to have new-* become a dynamic prefix which will very likely break tons of scripting out there.

Also, if we decide to introduce v2-, we have a different kind of inconsistency in the event that a 3rd gen UI becomes available as tech-preview in a hypothethical future cabal-3.12 version.

  • for cabal-1.24 through cabal-3.10, new-* refers to the 2nd gen UI
  • for cabal-3.12 and later, new-* changes its meaning and refers to to the 3rd gen UI
  • starting with cabal-2.2.1 (NB: cabal-2.2.1 may never end up in a Haskell Platform release if GHC 8.4.4 is never released) v1- and v2- become available, and refer to the 1st and 2nd gen UI
  • starting cabal-3.12 and later, v3-* refers to to the 3rd gen UI

So the trade-off here is, either

  • With the scheme above which changes the meaning of new-*, you'd be forced to change all your new-build-based scripts that were written over the last 2-3 years to remain well-defined (NB: v2- didn't exist yet in cabal-1.24, cabal-2.0 and cabal-2.2; so such scripting would have to require cabal-2.2.1 or later just for the sake of using the v2- prefix). So you'd suffer breakage for the benefit of avoiding an admittedly unfortunate naming weirdness or

  • with the pragmatic scheme outlined in #5399 (comment), We stomach the naming weirdness, but in return we don't force all the scripting out there based on the new-* prefix to rename to v2-

In hindsight, we should have introduced v1- and v2- prefix synonyms (pointing to build and new-build respectively) back w/ cabal-1.24; but unfortunately we didn't. So now we're faced with a choice between two non-optimal tradeoffs. While I'm still leaning towards my suggestion, I'm not married to it.

Member

hvr commented Jul 13, 2018

@ekmett yes, in hindsight, having used new-* at all was probably not ideal. We should have used v2- right-away; but now we're faced with the choice whether to have new-* become a dynamic prefix which will very likely break tons of scripting out there.

Also, if we decide to introduce v2-, we have a different kind of inconsistency in the event that a 3rd gen UI becomes available as tech-preview in a hypothethical future cabal-3.12 version.

  • for cabal-1.24 through cabal-3.10, new-* refers to the 2nd gen UI
  • for cabal-3.12 and later, new-* changes its meaning and refers to to the 3rd gen UI
  • starting with cabal-2.2.1 (NB: cabal-2.2.1 may never end up in a Haskell Platform release if GHC 8.4.4 is never released) v1- and v2- become available, and refer to the 1st and 2nd gen UI
  • starting cabal-3.12 and later, v3-* refers to to the 3rd gen UI

So the trade-off here is, either

  • With the scheme above which changes the meaning of new-*, you'd be forced to change all your new-build-based scripts that were written over the last 2-3 years to remain well-defined (NB: v2- didn't exist yet in cabal-1.24, cabal-2.0 and cabal-2.2; so such scripting would have to require cabal-2.2.1 or later just for the sake of using the v2- prefix). So you'd suffer breakage for the benefit of avoiding an admittedly unfortunate naming weirdness or

  • with the pragmatic scheme outlined in #5399 (comment), We stomach the naming weirdness, but in return we don't force all the scripting out there based on the new-* prefix to rename to v2-

In hindsight, we should have introduced v1- and v2- prefix synonyms (pointing to build and new-build respectively) back w/ cabal-1.24; but unfortunately we didn't. So now we're faced with a choice between two non-optimal tradeoffs. While I'm still leaning towards my suggestion, I'm not married to it.

@tom-bop

This comment has been minimized.

Show comment
Hide comment
@tom-bop

tom-bop Jul 13, 2018

Is there a cost to simply having a v2-* alias that points to (what's currently called) new-*?

That way we'd have

  • v1-*
  • v2-* <-- new-* is an alias to this but over the years that could be deprecated and the new-* alias could gradually be freed up for future use (or not!)
  • v3-*

tom-bop commented Jul 13, 2018

Is there a cost to simply having a v2-* alias that points to (what's currently called) new-*?

That way we'd have

  • v1-*
  • v2-* <-- new-* is an alias to this but over the years that could be deprecated and the new-* alias could gradually be freed up for future use (or not!)
  • v3-*

@typedrat typedrat merged commit 83120cd into haskell:master Jul 13, 2018

9 of 10 checks passed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
linux-7.6.3 Downstream Travis
Details
linux-8.0.2 Downstream Travis
Details
linux-8.2.2 Downstream Travis
Details
linux-8.4.3 Downstream Travis
Details
linux-8.4.3-fdebug-expensive-assertions Downstream Travis
Details
osx-7.10.3 Downstream Travis
Details
osx-7.8.4 Downstream Travis
Details
osx-8.0.2 Downstream Travis
Details

@typedrat typedrat moved this from In Progress to Done in Have new-build become build (GSOC2018) Jul 13, 2018

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