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.

Sign up for GitHub

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

Jump to bottom

Dependency as constraint vs Dependency as dependency #5570

Closed
fgaz opened this issue Sep 7, 2018 · 0 comments
Closed

Dependency as constraint vs Dependency as dependency #5570

fgaz opened this issue Sep 7, 2018 · 0 comments
Assignees
@fgaz
Milestone
3.4.0.0-rc1

Comments

@fgaz
Copy link
Member

fgaz commented Sep 7, 2018 •
edited
Loading

Just opening this to keep track of how Dependency is used throughout the codebase for when we'll split it

See https://github.com/fgaz/gsoc/blob/master/2018/final-report.md#the-dependency-as-constraint-problem

  • Dependency as constraint
    • configConstraints
    • Client/Outdated and packageConstraintToDependency
    • maaaybe the two lookupDependencys
  • Dependency as dependency on library
    • build-depends obviously
    • setup-depends
    • DependencyMap and similar
  • Dependency as "dependency" (more like... package source? hint? it's not even used..) on package
    • ProjectConfig.projectPackagesNamed

Other things to remove when doing the refactor:

  • Types/Dependency.hs:
    • thisPackageVersion
    • notThisPackageVersion
@fgaz fgaz self-assigned this Sep 7, 2018
@fgaz fgaz mentioned this issue Dec 23, 2018
Closed
phadej added a commit to phadej/cabal that referenced this issue May 8, 2020
@phadej
Add Described PackageVersionConstraint
530b062 
First step towards haskell#5570
@phadej phadej mentioned this issue May 8, 2020
Merged
phadej added a commit to phadej/cabal that referenced this issue May 8, 2020
@phadej
Add Described PackageVersionConstraint
e6fe442 
First step towards haskell#5570
phadej added a commit to phadej/cabal that referenced this issue May 8, 2020
@phadej
Add Described PackageVersionConstraint
2c27ddf 
First step towards haskell#5570
@phadej phadej closed this as completed in 867e45e May 9, 2020
@phadej phadej mentioned this issue Jul 10, 2020
Merged
@phadej phadej added this to the 3.4.0.0-rc1 milestone Jul 13, 2020
sternenseemann added a commit to sternenseemann/cabal2nix that referenced this issue Jun 10, 2021
@sternenseemann
Support Cabal 3.4.0.0
46abfc3 
finalizePD uses PackageVersionConstraint instead of dependency since
3.4.0.0 (see also haskell/cabal#5570).
This is a bit annoying since we need to do some CPP-stuff to support
both 3.2.* and 3.4.0.0, but it is a good opportunity to clean up our use
of Dependency: Since we always ignore the `LibraryName`s in `Dependency`
and it is required to be a `NonEmptySet` since 3.4.0.0, we switch to
using the simpler `PackageVersionConstraint` which doesn't care about
`LibraryName` at all (just like us).
sternenseemann added a commit to sternenseemann/cabal2nix that referenced this issue Jun 10, 2021
@sternenseemann
Support Cabal 3.4.0.0
2e7dca9 
finalizePD uses PackageVersionConstraint instead of dependency since
3.4.0.0 (see also haskell/cabal#5570).
This is a bit annoying since we need to do some CPP-stuff to support
both 3.2.* and 3.4.0.0, but it is a good opportunity to clean up our use
of Dependency: Since we always ignore the `LibraryName`s in `Dependency`
and it is required to be a `NonEmptySet` since 3.4.0.0, we switch to
using the simpler `PackageVersionConstraint` which doesn't care about
`LibraryName` at all (just like us).
Profpatsch pushed a commit to Profpatsch/cabal2nix that referenced this issue Mar 7, 2022
@sternenseemann @Profpatsch
Support Cabal 3.4.0.0
717e51f 
finalizePD uses PackageVersionConstraint instead of dependency since
3.4.0.0 (see also haskell/cabal#5570).
This is a bit annoying since we need to do some CPP-stuff to support
both 3.2.* and 3.4.0.0, but it is a good opportunity to clean up our use
of Dependency: Since we always ignore the `LibraryName`s in `Dependency`
and it is required to be a `NonEmptySet` since 3.4.0.0, we switch to
using the simpler `PackageVersionConstraint` which doesn't care about
`LibraryName` at all (just like us).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fgaz fgaz

Labels
None yet
Projects
None yet
Milestone
3.4.0.0-rc1
Development

No branches or pull requests
2 participants
@phadej @fgaz