Skip to content

Revert style2str change in b547ead58bf09bb838c13f02afb2f1042ad1bc7c #8722

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

Closed
wants to merge 1 commit into from

Conversation

phadej
Copy link
Collaborator

@phadej phadej commented Feb 1, 2023

if elabLocalToProject says package is local, than it is. inplace packages are things which depend on local packages, but don't have local sources. (e.g. hackage-security in Cabal project). And global packages are the ones which can go to the store.

The original change didn't include changelog for this part of the change nor tests, so it's an easy revert.

if elabLocalToProject says package is local, than it is.
`inplace` packages are things which depend on local packages,
but don't have local sources. (e.g. hackage-security in Cabal project).
And global packages are the ones which can go to the store.
@phadej
Copy link
Collaborator Author

phadej commented Feb 1, 2023

Ok, so this doesn't work as simply either. I wonder what the failing tests does

       -- | Is this package one of the ones specified by location in the
       -- project file? (As opposed to a dependency, or a named package pulled
       -- in)
       elabLocalToProject         :: Bool,

       -- | Are we going to build and install this package to the store, or are
       -- we going to build it and register it locally.
       elabBuildStyle             :: BuildStyle,

field description doesn't seem to suggest these are coupled. There are only three valid combinations of these three though (arguably)

  • local=False, buildStyle=BuildInplaceOnly: (inplace) e.g. packages pulled from Hackage, which depend on project packages (hackage-security)
  • local=False, buildStyle=BuildAndInstall: (global)dependencies, e.g. async
  • local=True, buildStyle=BuildInPlaceOnly: (local) project packages, package: Cabal.
  • local=True, buildStyle=BuildAndInstall: AFAIU this shouldn't happen. We shouldn't install local packages to store. (We can sdist them, making them non-local, and then install).

inplace and local should have dist-dir as they are built inplace (BuildInplaceOnly) to the project. global packages are not built (they can be in store cache).

@phadej
Copy link
Collaborator Author

phadej commented Feb 1, 2023

As this is not as easy fix as I hoped I close the PR. The issue is there for grabs

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.

1 participant