Pub: Automatic Version Solving like JuliaLang's Pkg.jl

[hpoit]

Have a look at this pkg manager design https://julialang.github.io/Pkg.jl/stable/

Will automatic version solving be in DartLang's roadmap?

[jakemac53]

Please list specifically what you want. "Automatic version solving" sounds like what pub already does.

[hpoit]

There is no version solving failure in Julia's Pkg. That's my wish.

[jakemac53]

This doesn't really have anything to do with the package manager. It is not going to allow versions outside of the allowed constraints, so there will always be scenarios you can get into which can't give you a valid version solve.

[jakemac53]

(note that dependency_overrides exist to work around this for the cases where you know a valid version but it wouldn't be allowed by the constraints of the published packages)

[hpoit]

https://dart.dev/tools/pub/dependencies#dependency-overrides is a temporary fix.

This issue/wish is not solved.

[natebosch]

There is no version solving failure in Julia's Pkg.

That is false. Here is an example of what a version solving failure looks like in Pkg:

https://discourse.julialang.org/t/compatibility-issues-how-to-read-the-error/26188

Any version solver _must_ deal with unsatisfiable constraints. Having not personally experienced a failure does not indicate they don't exist.

This issue is not actionable.

[hpoit]

Yes it is actionable: why does version solving in Dart fail _so_ often?

[jonasfj]

I haven't read about Julie's Pkg, I might put that on my todo list.

---

why does version solving in Dart fail so often?

I suspect version resolution fails because pub doesn't allow you to install two versions of the same package. See: https://dart.dev/tools/pub/versioning

The pros for supporting many versions of the same package is mainly that you don't get conflicts (at-least they are very rare, as is the case in the npm eco-system). The downsides are:

• Bloat, because you can installed many versions of the same package the size of dependencies can explode.
• Type compatibility, types from one version of a package is incompatible with types for a different version of the same package, this causes issues that are hard to understand.

At the moment, Dart doesn't have the infrastructure for supporting multiple versions of the same package. It might be worthwhile reconsidering this at some point, though refactoring the infrastructure to support this would be complicated and require language changes.

But there is also a lot of simplicity to only supporting a single version of the same package.

[hpoit]

Hi Jonas. Thanks for the insight! How does Julia deal with dependency explosion? Shouldn't all types within one version be used in isolation (environment) wrt to another version? These are other questions worth analyzing. User experience goes from the final users of the products we devs make, to ourselves, devs. Thanks for this comment.

[jonasfj]

Shouldn't all types within one version be used in isolation (environment) wrt to another version?

A public member in package A can return a type defined in package B. So if your program has two versions of package B in the dependency graph you could get some weird cases. Notably, the import paths would have to specify which version to import, or imports would have to be context sensitive.
(Do you suggest that this shouldn't be possible?)

[hpoit]

It seems version solving becomes harder when package A depends on a type defined in package B1, B2, B3, ... instead of just B1. Wouldn't it be easier if each new package A depended on only one package B, forcing package B2 to include all features of B1, so B1 can be completely replaced by B2?

[hpoit]

"In other words, it’s hard to imperatively change a widget from outside, by calling a method on it. And even if you could make this work, you would be fighting the framework instead of letting it help you." "In declarative frameworks like Flutter, if you want to change the UI, you have to rebuild it."

These Flutter comments could be used here: If you want to change the dependency graph, you have to rebuild it. Construct the graph once, and do not allow methods? That's a closer abstraction to how hardware works.

"You would need to take into consideration the current state of the UI and apply the new data to it. It’s hard to avoid bugs this way."

[hpoit]

Establish that all succeeding B versions be backwards compatible with previous B versions, so each succeeding B version (current state) can completely replace a previous B version (previous state)?

[hpoit]

"When building production quality applications, managing state becomes critical." https://felangel.github.io/bloc/#/whybloc Felix is a senior software engineer at BMW NA.

[hpoit]

I read some of Flutter's docs yesterday and will finish it today. I realized Bloc is heavily inspired on Flutter, or state management, which makes absolute sense wrt hardware.

[hpoit]

Flutter is pretty much re-educating frontend engineers to work correctly based on hardware.

[hpoit]

"By only using add your Manifest will always have a "reproducible state", in other words, as long as the repositories and registries used are still accessible it is possible to retrieve the exact state of all the dependencies in the project." This would do wonders for deprecated libraries in AngularDart! No more wasting time with pubspec.yaml!

https://julialang.github.io/Pkg.jl/stable/managing-packages/#Developing-packages-1

[hpoit]

"This has the advantage that you can send your project (Project.toml and Manifest.toml) to someone else and they can "instantiate" that project in the same state as you had it locally. However, when you are developing a package, it is more convenient to load packages at their current state at some path. For this reason, the dev command exists." Same Julia source.