[feature] Version ranges for editable packages

[J1NX1337]

What is your suggestion?

OS: Windows 11
Conan version: 2.11.0

Hi! I don't know whether this should be considered a bug or lack of a feature, so I'm just labelling it as the latter for now.

Conan does not seem to recognize when adding an editable package with a wildcard version, or a version range e.g.: conan editable add <package> --version=* or conan editable add <package> --version=[>1.0].

The documentation doesn't seem to mention anything about this: https://docs.conan.io/2/tutorial/developing_packages/editable_packages.html
However, considering how version ranges and wildcard syntax are supported in most other Conan commands, I would have expected this to be possible as well. Even conan editable remove --refs=* uses the wildcard syntax.

Our company is developing an application and an SDK, which is a dependency of this application. For now, they are organized in a monorepo. I have recently turned the SDK into a Conan package to leverage Conan's multitude of features. When merging MRs that contain changes to the SDK to our target branch in CI, the CI system will auto-increment the SDK Conan package version as well as the version of it required by our application.

Now when our developers are working on local changes to test the SDK changes with the application, I've instructed them to use Conan's editable packages method, and then build the application with conan build app --build=editable. However, while doing so, they need to constantly make sure that the latest version of our SDK Conan package is in editable mode, which requires running the conan editable add command nearly every day, which can be bit of a nuisance.

Thus, the use case for having version ranges in editable packages would be to allow developers to more easily switch these local editable package builds on or off without having to label each individual version separately as "editable".

I would also like to add that we prefer the "editable packages" method to conan create with its (quite slow in our case) "exporting sources", or having to run multiple commands (conan build, conan export-pkg, conan build again) for local development.

Maybe there's also an alternative workflow that you could recommend us, in case we are somehow misusing the editable packages feature?

=====================================================

Repro steps:

git clone https://github.com/conan-io/examples2.git
cd examples2/tutorial/developing_packages/editable_packages

Edit say/conanfile.py and delete the "version attribute".
Define a set_version method referring to a file (e.g. json file) with a version number inside it:

import os
import json

def set_version(self):
      version_path = os.path.join(self.recipe_folder, "conan-version.json")
      try:
          with open(version_path, "r") as version_file:
              version_json = json.load(version_file)
              self.version = version_json["version"]

Then:

conan editable add say --version=*
conan build hello --build=editable

Expectation:
"say" and "hello" packages are built, and the "hello" package will use the local binaries of "say".
Actual:
"hello" package will attempt to download say/1.0 from a Conan remote.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @J1NX1337

Thanks for your feedback.

Conan does not seem to recognize when adding an editable package with a wildcard version, or a version range e.g.: conan editable add --version=* or conan editable add --version=[>1.0]

Yes, this is by design. The reason is that it is not possible to have a version range in an editable folder, you can only have one specific version in a folder, you cannot have simultaneously different versions. At any given time, the recipe is one and the code is just one instance of the code for that package, so only one version can represent its contents. What is possible is that a version that is in editable mode can satisfy multiple version ranges requirements from different consumers.

However, considering how version ranges and wildcard syntax are supported in most other Conan commands, I would have expected this to be possible as well. Even conan editable remove --refs=* uses the wildcard syntax.

Because this is pattern matching (different than version ranges) and this can work because the editables in the folder versions are well defined. The -refs in the argument of conan editable remove is a requirement type which makes sense to be a pattern or a version range, whereas the version of an editable is that, a version. In the same way it is not possible to do version = "[>1.0 <2]" in a recipe, Conan will error, it is not possible to define the version of an editable as a version range.

I think what you are looking for is the new incubating workspace feature: https://docs.conan.io/2/incubating.html

Note that one of the first requested and already implemented features is the capability of dynamically defining the versions of the editables packages, by being able to invoke the set_version() method. If I understood correctly, this might be what you are looking for?