pub outdated fails when overridden package has no hosted version

[FaFre]

I encounter the problem with pub 2.17.6 that pubspec_overrides.yaml is not taken into account for local (non-published) packages.

pubspec.yaml:

dependencies:
  local_package: any

pubspec_overrides.yaml:

dependency_overrides:
  local_package:
    path: ../../utils/local_package

Output of dart pub outdated:
Package not available (could not find package local_package at https://pub.dartlang.org).

On the other hand dart pub upgrade is working as expected and upgrades other dependencies accordingly. It also prints the warning that overrides are used:
Warning: pubspec.yaml has overrides from pubspec_overrides.yaml

[leehack]

I'm experiencing the same issue while using the melos.
It's not reproducible if the same package name exists in the pub.dev
For the moment, I use the relative path directly in the pubspec.yaml to bypass the issue for private packages.

[fnicastri]

this is very inconvenient,
melos and pubspec_overrides are a great way to
manage big codebases and this is a blocking issue.

any hope this will be fixed?

;)

[thipokch]

@sigurdm FYI, this is also applies to pub upgrade as well. It also affects mono-repo tools like melos (see discussion: invertase/melos#385 )

[thipokch]

As a workaround... I found that listing the path itself, instead of pubspec_override works.

mypackage:
    path: ../../path/to/package

[sigurdm]

I tested this locally, and to me it seems pub outdated does take pubspec_overides.yaml into account. (I.e. it has the same behaviour as if you add dependency_overrides to your main pubspec.yaml file.

As a workaround... I found that listing the path itself, instead of pubspec_override works.

Yeah - I don't think using an override (neither in pubspec.yaml nor pubspec_overrides.yaml) is the right thing if the dependency doesn't also exist elsewhere. In that case you should simply add a path-dependency: https://dart.dev/tools/pub/dependencies#path-packages

@FaFre does that also work for you - or am I misunderstanding something?

pubspec_overrides.yaml should only be used when the local resolution should differ from the public - but here it seems there is no "public" version of local_package....

[fnicastri]

In my opinion an override should override everything everywhere.
I expect that if I override something, in pubspec_overrides.yaml or in pubspec.yaml itself, every tool will honor my override.
Im my case I have many private (for now) packages in project_root/packages and I use them in project_root/app/flutter_project managing the "linking" with melos.
Everything is working fine except pub outdated.
Many of these packages are private, they will never be published manly because they are strictly related to the project or because are related to our private APIs. Others are forks of published packages (they will be published one day), custom adaption, just experiments, etc etc

Managing these exceptions thru pubspec_overrides (with Melos) is awesome, it would be a pity to renounce to part of that utility/workflow for this.

f.

[sigurdm]

If the packages are private and local the right mechanism to use is path-dependencies.
dependency_overrides is (as the name implies) for overriding another dependency.

Not sure what to suggest here. I think #3502 (comment) is the right solution - what extra does melos give you in this case? (I have never used melos myself, so I don't know the intimate workings).

[fnicastri]

what extra does melos give you in this case? (I have never used melos myself, so I don't know the intimate workings).

Basically complete management of the workspace.
Included management of the packages and their publishing/versioning.

from the website:

• Automatic versioning & changelog generation.
• Automated publishing of packages to pub.dev.
• Local package linking and installation.
• Executing simultaneous commands across packages.
• Listing of local packages & their dependencies.

Anyway, imo, if there is an override it should override everything,
who cares about an eventual public version if I'm using a local one?
I mean, sometimes you care, sure, some other times you don't.
Probably a warning/info could be better that failing.
But I don't want to push on this.

Thanks
f.

[sigurdm]

from the website:

who cares about an eventual public version if I'm using a local one?

I was more thinking - why do you need melos to manage the relationship between two local packages? - just use a path dependency.

That is the established way in pub to express this relationship, an override is for expressing an exception to the default dependency resolution.

Have you tried to rise the issue with the maintainers of melos?

[fnicastri]

@sigurdm

I think the focal point was:

if there is an override it should override everything,

---

about:

I was more thinking - why do you need melos to manage the relationship between two local packages? - just use a path dependency.

Simply to use the same tool to manage everything,
local, public, forked packages.

To add the last piece: do you think is normal for a tool like pub to
just exit with an error just because it can't find a package?
What about just a warning?
just my 2 cents

anyway thank you for your time

[sigurdm]

Thanks for being persistent here! :)

I reproduced locally, and there indeed seems to be a bug in dart pub outdated... the error happens when it tries to find the 'latest' version - it should just return null instead of throwing.

(I still think dependency_overrides are the wrong tool here semantically - but I'm not sure it matters much)

I'll make a fix - with that fix I think the command should be working for your use case.