Skip to content
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
Merged

Finish new-install #5399

merged 39 commits into from Jul 13, 2018

Conversation

@typedrat
Copy link
Collaborator

@typedrat 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
let verbosity' = lessVerbose verbosity

-- First, we need to learn about what's available to be installed.
localBaseCtx <- establishProjectBaseContext verbosity' cliConfig

This comment has been minimized.

@alexbiehl

alexbiehl Jun 26, 2018
Member

Does this create the dist-newstyle folder in $PWD? We should clean up after this in case we are not in a project context if it does.

This comment has been minimized.

@typedrat

typedrat Jun 26, 2018
Author Collaborator

Oh, no. That doesn't create a fake context, that's creating a real context in the current project... but that breaks out of project installs. Oops.

This comment has been minimized.

@alexbiehl

alexbiehl Jun 26, 2018
Member

yeah, I know... I tried real hard to refactor that stuff once. But there is a chicken/egg problem with establishing the project context and file monitor caching in dist-newstyle...

@typedrat typedrat force-pushed the typedrat:new-install branch from f09768b to 96196b8 Jun 26, 2018
@typedrat
Copy link
Collaborator Author

@typedrat 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
Author 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.

@typedrat

typedrat Jul 2, 2018
Author Collaborator

Hmm, how would I get around that...

This comment has been minimized.

@andreasabel

andreasabel Dec 21, 2020

Not sure that removing the vowels guarantees any shortening of the name, or contributes big savings.
In any case, it is quite alienating to look into .cabal/store and see that the Grinch stole all the vowels.
I am feeling like I am trolled here, or there was some jester in the team developing the new cabal, and that jester is trying to make fun of the Haskell programmers.

This comment has been minimized.

{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE RecordWildCards #-}
module Distribution.Client.CmdInstall.EnvironmentParser

This comment has been minimized.

@fgaz

fgaz Jul 2, 2018
Collaborator

Shouldn't this be in Distribution.Simple.GHC?

This comment has been minimized.

@typedrat

typedrat Jul 2, 2018
Author Collaborator

I wasn't sure if it was of general enough applicability, but it's easy enough to move it.

@alexbiehl
Copy link
Member

@alexbiehl alexbiehl commented Jul 3, 2018

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

@23Skidoo
Copy link
Member

@23Skidoo 23Skidoo commented Jul 3, 2018

Just rebase.

@typedrat typedrat force-pushed the typedrat:new-install branch from 0fbd56c to 066dec7 Jul 3, 2018
@@ -53,10 +53,14 @@ module Distribution.Simple.GHC (
isDynamic,
getGlobalPackageDB,
pkgRoot,
-- * Constructing GHC environment files
-- * Constructing and deconstsructing GHC environment files

This comment has been minimized.

@tom-bop

tom-bop Jul 6, 2018

s/deconstsructing/deconstructing/

@typedrat
Copy link
Collaborator Author

@typedrat 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.

@@ -320,6 +320,7 @@ library
zlib >= 0.5.3 && < 0.7,
hackage-security >= 0.5.2.2 && < 0.6,
text >= 1.2.3 && < 1.3,
parsec >= 3.1.13.0 && < 3.2,

This comment has been minimized.

@tom-bop

tom-bop Jul 6, 2018

I see a note in this file: NOTE: when updating build-depends, don't forget to update version regexps in bootstrap.sh.

This comment has been minimized.

@tom-bop

tom-bop Jul 6, 2018

Also, is there a less-heavyweight library we could use, to decrease the size of the chicken-or-egg problem here? (Thx for this work, btw!)

This comment has been minimized.

@typedrat

typedrat Jul 6, 2018
Author Collaborator

Cabal the library already uses parsec anyway.

@typedrat typedrat changed the title [WIP] Finish new-install Finish new-install Jul 6, 2018
@typedrat typedrat added this to the 2.4 milestone Jul 7, 2018
@typedrat
Copy link
Collaborator Author

@typedrat typedrat commented Jul 7, 2018

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

@quasicomputational
Copy link
Contributor

@quasicomputational 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.

Copy link
Contributor

@quasicomputational quasicomputational left a comment

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
Contributor

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
Author 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. :)

, sdistProjectFile = projectConfigProjectFile (projectConfigShared cliConfig)
}

sdistAction sdistFlags ["all"] globalFlags

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

This feels like the wrong level of interface granularity. The sdist code is going to have to go through the hoops of target parsing, output directory logic, and we're re-wrapping the verbosity in a flag. Can CmdSdist export a more convenient function for this?

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

It even has that, just about, and I'm not at all sure why I'm using the sdistAction.

@@ -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
Contributor

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
Author Collaborator

Yep.

GhcEnvFileClearPackageDbStack
: fmap GhcEnvFilePackageDb packageDbs
entries = baseEntries ++ entriesForLibraryComponents (targetsMap buildCtx)
createDirectoryIfMissing True (takeDirectory envFile)

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

If we're bothering to avoid creating .environment files on old GHCs, shouldn't the above lines be under the when?

@@ -199,13 +402,37 @@ installAction (configFlags, configExFlags, installFlags, haddockFlags)
traverse_ (symlinkBuiltPackage verbosity mkPkgBinDir symlinkBindir)
$ Map.toList $ targetsMap buildCtx
runProjectPostBuildPhase verbosity baseCtx buildCtx buildOutcomes

unless supportsPkgEnvFiles $
warn verbosity "The current compiler doesn't support safely installing libraries. (GHC 8.0+ only)"

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

Since this means that libraries aren't installed, I think it should say that rather than mentioning 'safely' here.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

I'm intending it as "doesn't support doing it safely (so we're not doing it at all)". Could be clearer though.

sdistAction sdistFlags ["all"] globalFlags

(specs, selectors) <- withInstallPlan verbosity' localBaseCtx $ \elaboratedPlan -> do
-- Split into known targets and hackage packages.

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

The code under here is really deeply nested. Can we consider lifting some of this out, or are there so many local variables involved that it's annoying?

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

There's heavy enough cross-involvement that the drop in complexity for lifting bits out is more than made up for by the increase from having to directly plumb everything. I wrote it split out originally but I was passing the same arguments over and over often enough I manually inlined it into that code there.

``cabal new-install [FLAGS] PACKAGES`` builds the specified nonlocal packages
and symlinks their executables in ``symlink-bindir`` (usually ``~/.cabal/bin``).
``cabal new-install [FLAGS] PACKAGES`` builds the specified packages, adds their
libraries into the default environment and symlinks their executables in

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

Should probably link to the GHC manual describing package environments.

I think we also need to describe the practical effects of this. The GHC docs say this:

Note the implicit -hide-all-packages and the fact that it is -package-id ⟨unit-id⟩, not -package ⟨pkg⟩. This is because the environment specifies precisely which packages should be visible.

So if I don't have a default package environment before, then I cabal new-install something, and now every manual GHC invocation will have an implicit -hide-all-packages. I am not sure this is going to make users happy.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

Well, that's only a real issue if you are using both install commands at once. I'm personally comfortable saying "don't do that, then", but that's just me.

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

IIUC this will also apply to, e.g., packages installed to the global store using the system package manager as well. I'd be okay with saying that v1-install and new-install don't play nicely together but I'm more hesitant about that interaction.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

Hmm... We could just include all of the global packages.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

My personal opinion is that the package manager's packages are for system dependencies not for building software locally.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

Thinking further, exposing package manager packages is an emphatic Bad Choice, as far as I'm concerned. That greatly expands the burden in terms of creating a consistent install plan, and will likely end up with a lot of situations where you are stuck on old version because you need some random (and likely antique) version of text or something because that's what the package manager provides.

envEntries <- if
| compilerFlavor == GHC || compilerFlavor == GHCJS
, supportsPkgEnvFiles
, envFileExists -> readGhcEnvironmentFile envFile

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

If a failure to install libraries isn't fatal because GHC is old, then I think we should gracefully handle an extant-but-unparseable default package environment by warning about that and then installing the executables anyway.

createDirectoryIfMissing True (takeDirectory envFile)
when supportsPkgEnvFiles $ do
let
entries' = nub (envEntries ++ entries)

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

First, is this nub absolutely never going to go wrong and lead to a non-Cabal-generated package environment being destroyed, including, e.g., making it easy to roll back Cabal's changes?

Second, a user might install many thousands of packages. ordNub is O(n log n), so go for that instead.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

This code generally considers that env as belonging to Cabal, but that isn't explicit. Either needs the code to change or the docs to call out that we own that file.

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

A mention in the docs that Cabal considers this file its property ought to suffice.

configCompilerEx hcFlavor hcPath hcPkg progDb verbosity

let
envFile = home </> ".ghc" </> ghcPlatformAndVersionString platform compilerVersion

This comment has been minimized.

@quasicomputational

quasicomputational Jul 7, 2018
Contributor

If new-install grows a --target-environment flag that takes a file naming the environment to write to, rather than always being the default package environment, then I think testing this code gets a lot simpler.

This comment has been minimized.

@typedrat

typedrat Jul 7, 2018
Author Collaborator

Agreed.

@typedrat
Copy link
Collaborator Author

@typedrat typedrat commented Jul 7, 2018

Should have fixed your issue, @quasicomputational.

@typedrat
Copy link
Collaborator Author

@typedrat typedrat commented Jul 7, 2018

Why is there a parse error only on 7.10?

@quasicomputational
Copy link
Contributor

@quasicomputational quasicomputational commented Jul 7, 2018

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

@typedrat
Copy link
Collaborator Author

@typedrat typedrat commented Jul 7, 2018

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

@quasicomputational
Copy link
Contributor

@quasicomputational 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
Copy link
Collaborator Author

@typedrat typedrat commented Jul 7, 2018

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

@typedrat
Copy link
Collaborator Author

@typedrat typedrat commented Jul 7, 2018

    print progDb

on line CmdInstall.hs:319 would be helpful.

@quasicomputational
Copy link
Contributor

@quasicomputational 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
typedrat added 2 commits Jul 10, 2018
@typedrat
Copy link
Collaborator Author

@typedrat 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
Copy link

@tom-bop tom-bop commented Jul 10, 2018

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

@typedrat
Copy link
Collaborator Author

@typedrat typedrat commented Jul 10, 2018

@tom-bop, that's correct.

@gbaz
Copy link
Collaborator

@gbaz 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
Copy link
Collaborator

@fgaz fgaz commented Jul 11, 2018

Or env, like nix

@andreabedini
Copy link

@andreabedini 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 mentioned this pull request Jul 11, 2018
4 of 4 tasks complete
@ekmett
Copy link
Member

@ekmett 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
Copy link
Collaborator Author

@typedrat 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
Copy link
Member

@ekmett 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
Copy link
Collaborator Author

@typedrat 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 mentioned this pull request Jul 12, 2018
3 of 3 tasks complete
@typedrat typedrat force-pushed the typedrat:new-install branch from 1e1188f to 56939d8 Jul 12, 2018
@hvr
Copy link
Member

@hvr 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
@typedrat typedrat force-pushed the typedrat:new-install branch from 56939d8 to 7d961eb Jul 12, 2018
@ekmett
Copy link
Member

@ekmett 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
Copy link
Member

@hvr 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
Copy link

@tom-bop 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
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
Projects
Linked issues

Successfully merging this pull request may close these issues.

None yet