[question] Editables not considered for version ranges

[fourbft]

What is your question?

Say you have two packages pa and pb where pb uses pa via a version range. (E. g. self.requires("pa/[>1.0]"))
You can now create the packages pa (version 1.0.0) and pb (version 2.0.0).
Now I want to make changes to pa and test those changes with pb. So I increase the version of pa to e. g. 1.0.1 and put it in "editable" mode. Then I have a pa/1.0.0 in the local cache and a pa/1.0.1 in the list of editables.
When I now recreate package pb, it still uses pa/1.0.0 from the cache instead of the newer editable package. If I delete pa/1.0.0 from the cache and try to recreate pb, I get an error message: ERROR: Package 'pa/[>1.0]' not resolved: Version range '>1.0' from requirement 'pa/[>1.0], Traits: ... required by 'pb/2.0.0' could not be resolved. even though there is a pa/1.0.1 in the editables list.
When I change the recipe of pb to self.requires("pa/1.0.1") then the editable pa package is used as expected.

Question is: Am I missing something or do version ranges ignore the editable packages alltogether?

Depending on the answer, feel free to change the type of this issue to "bug report" or "featue request". 😃

(I am using Conan version 2.0.9, btw.)

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[fourbft]

Ok, after some experimenting, I did find two workarounds:

When I capture pb in a lockfile (conan lock create .) and then add the editable version of pa to the lockfile (conan lock add --requires pa/1.0.1) then I can create a pb binary package which uses the editable package without modifying the pb recipe.

Also, when I create a conanfile.txt that contains both, pb/2.0.0 and the editable pa/1.0.1 and then install that conanfile.txt with --build missing I also get a pb package that uses the pa editable version.

Still, wouldn't it be more "natural" if version ranges would take the editables into account on their own?

[memsharded]

Thanks for the report @fourbft and the suggestions.

I think it make sense to support this natively (it was not previously considered, so more a feature than a bug, but it really doesnt matter)

Proposing #14510 for next 2.0.10 release, in case you want to give a try from sources.

[memsharded]

#14510 merged, it will be in next 2.0.10 release.

[fourbft]

Thanks for the super quick fix @memsharded!

Tried the 2.0.10-dev version from your #14510 PR sources and it works perfectly in my scenario!