Skip to content

Parameterize SourcePackage and ConfiguredPackage on package location #3210

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

Merged
merged 2 commits into from
Mar 6, 2016

Conversation

BardurArantsson
Copy link
Collaborator

This is a step towards breaking the dependency from the modular
solver on cabal-install.

@BardurArantsson
Copy link
Collaborator Author

I should say: The reason we want to break the "PackageLocation" dependency is that it brings in a lot of unnecessary baggage, namely URI (i.e. the network package), etc. I can't recall all the details, but ISTR it also brings in other parts of cabal-install which aren't needed for the solver.

@BardurArantsson
Copy link
Collaborator Author

Most of the remainder of splitting out the solver into its own library "between" Cabal and cabal-install is just moving files around and splitting up Distribution.Client.Types appropriately.

I think we can hold off on that for a bit if we still want to keep master close to 1.24.x for a while. This bit is the most code-edit heavy bit.

@BardurArantsson
Copy link
Collaborator Author

/cc @kosmikus @hvr

@23Skidoo
Copy link
Member

23Skidoo commented Mar 5, 2016

Looks harmless enough, the only complaint is bikeshedding: the PackageLocation' type name is pretty uninformative. Maybe we could have something like UnresolvedPackageLocation = PackageLocation (Maybe FilePath) and ResolvedPackageLocation = PackageLocation FilePath instead? Better naming suggestions welcome, of course.

@BardurArantsson
Copy link
Collaborator Author

That's a good point. I'll have a look at it tomorrow.

@BardurArantsson
Copy link
Collaborator Author

Looking over the other code, we have three variants:

  • PackageLocation (Maybe FilePath)
  • PackageLocation FilePath
  • PackageLocation ()

I'm not sure what that last one really represents.

My only concern about doing what you suggest is really that the names are a bit long... though obviously not as long as spelling out the full types. Would UnresolvedPkgLoc and ResolvedPkgLoc be acceptable? (Or maybe spell out Location in full?)

EDIT: I mean UnresolvedPackageLocation is 25 characters which is ~30% of the 80-column budget!

(BTW, if we're going to be systematic about it, this does involve changes in a few further places that this patch doesn't currently touch. It's not too bad, but worth mentioning.)

@BardurArantsson
Copy link
Collaborator Author

OK, so I've changed this to two commits:

  • The first commit was amended thus: Renamed PackageLocation' to UnresolvedPkgLoc and replaced stray instances of PackageLocation (Maybe FilePath) with the UnresolvedPkgLoc alias.
  • The second commit adds ResolvedPkgLoc and replaces instances of PackageLocation FilePath with a reference to the alias.

Hopefully that should be it.

Let me know if you'd like the longer names -- it's pretty trivial to do a global search/replace.

@ezyang
Copy link
Contributor

ezyang commented Mar 6, 2016

Sorry for ALL THE BIKESHEDS, but I'd be keen for an alias on SourcePackage UnresolvedPkgLoc too.

@BardurArantsson
Copy link
Collaborator Author

Can we please do that in a follow-up? I'd really like to get this merged ASAP since it's pretty prone to conflicts with other stuff.

@BardurArantsson
Copy link
Collaborator Author

@23Skidoo OK to merge?

@23Skidoo
Copy link
Member

23Skidoo commented Mar 6, 2016

@BardurArantsson

PackageLocation ()

I think we can leave this one as it is.

23Skidoo added a commit that referenced this pull request Mar 6, 2016
Parameterize SourcePackage and ConfiguredPackage on package location
@23Skidoo 23Skidoo merged commit e786c34 into haskell:master Mar 6, 2016
@23Skidoo
Copy link
Member

23Skidoo commented Mar 6, 2016

Merged, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants