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.

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

[feature] Dynamic versioning in workspaces #17306

Open
1 task done
aander80 opened this issue Nov 12, 2024 · 5 comments
Open
1 task done

[feature] Dynamic versioning in workspaces #17306

aander80 opened this issue Nov 12, 2024 · 5 comments
Assignees

Comments

@aander80
Copy link

What is your suggestion?

Hello!

If using dynamic versioning (for instance using dunamai then I imagine it could be a bit confusing and perhaps tedious to work with workspace where you are "locking" the version of an editable in conanws.yml. Every commit will produce a new version, and the version in conanws.yml will very quickly be out of sync with the actual version. The built binaries, if including metadata for its dependencies, will have incorrect information.

As an example of this, please have a look at my workspace test repo. There are instructions in README.md for setting it up. By setting up the repo and running ./example_scripts/version_mismatch.sh you will get different versions of liba, libb and app although they are the same in conanws.yml.

As a potential solution to this, I am thinking that you can specify name/* instead of name/version in conanws.yml, and conan workspace commands will dynamically and temporarily check the version of those packages, add them as editables during the current command, run the command, and at the end remove them as editables -- alternatively just updating existing editables at the start of the conan workspace command. Perhaps this is usable/possible with a conanws.py, although I have not been able to get it to work or understand how it is supposed to work.

This is also elaborated upon a bit in my test repo under the Version diff section.

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded memsharded self-assigned this Nov 12, 2024
@memsharded
Copy link
Member

Thanks very much for your feedback @aander80

I have done a quick proof of concept in a new test in a377ab7

See the workspace:

import os
name = "myws"

workspace_folder = os.path.dirname(os.path.abspath(__file__))

def editables():
    result = {}
    for f in os.listdir(workspace_folder):
        if os.path.isdir(f):
            name = open(os.path.join(f, "name.txt")).read().strip()
            version = open(os.path.join(f, "version.txt")).read().strip()
            result[f"{name}/{version}"] = {"path": f}
    return result

This assumes that name.txt and version.txt encode the dynamic information of the package.
I am happy to see that the current proposal for workspaces definition seems to be flexible.

Now, it is true that we might want to be able to provide some helpers or API to give access to some higher level builtin capabilities, like leveraging the recipe set_version()/set_name() to extract the data. This might require a bit more of thinking that this looks like a good start at least.

@memsharded
Copy link
Member

I managed to add in 6c023e3 a small API that allows loading Conanfiles for automatic invocation of set_name()/set_version(). Just a draft to discuss with the team ideas.

@aander80
Copy link
Author

That looks very promising! I tried using it but got error NameError: name 'workspace_api' is not defined when running conan workspace info. I don't know if it is expected to work quite yet outside of tests (or even the tests themselves) but I pushed a change in my test repo where I added conanws.py if you want to have a closer look. Otherwise I look forward to testing something once you have had a discussion with the team and have something ready to test! :)

@memsharded
Copy link
Member

memsharded commented Nov 12, 2024

I am not getting that error, but using your project I got another error:

Error in Conan initialization: conanfile.py: Error in set_version() method, line 23
        self.run("dunamai from git --style semver --bump", cwd=self.recipe_folder, stdout=stdout)
        AttributeError: 'NoneType' object has no attribute 'cmd_wrapper'

This is expected, the current implementation do not provide the cmd_wrapper, doesn't allow self.run() inside the set_version(). We would need a more complex construction of the conanfile to be able to support this.

@memsharded
Copy link
Member

And for real usage the code would be something like:

for f in os.listdir(workspace_api.folder):
        if os.path.isdir(f) and os.path.exists(os.path.join(f, "conanfile.py")):

Checking that the conanfile.py actually exists, to avoid error for other folders like .git that would fail otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants