pyproject.toml:tool.poetry.version as version_source
Description
Ability to make pyproject.toml's version as version_source for semantic-release
Use cases
I have multiple projects which are basically small monorepos. Each of them in some way depends on some common objects so it makes sense to have them in such fashion. They have their own pyproject.toml files and their own versioning.
Possible implementation
Maybe add some variable that will overwrite existing values for version_source. I can make PR if you are interested
Hey 👋
I'm not 100% sure I follow your issue - are you trying to update multiple pyproject.toml files in different subdirectories of a monorepo?
It should already be possible to use pyproject.toml:tool.poetry.version as version_toml in your configuration with version_source = "commit", or alternatively you could use your Git tags as a common place for a version with version_source = "tag"
I think the functionality already exists in PSR but you will need to reference your metadata through a combination of version_toml, version_variable and version_pattern rather than adding a new option to version_source
I have such structure:
|.
|-b
| |b.py
| |pyproject.toml
|a.py
|pyproject.toml
Project A can have version 1.5.0 and project B can have something like 2.6.8. I managed to get their own changelogs with custom parser that checks scope of the commit (something like feat(A): changes for project A and vice versa).
If we use version_source = "commit" or tag, it does not really matter - one of the projects looks at the wrong version number. I changed project A's version_source to commit and project B's to tag but it looks like a pretty bad solution. What if I add project C and project D with their respective versions?
I think this change can be pretty convenient for some users
Ah I see - I would file this under "monorepo support". You might be able to get some mileage out of #509, but PSR doesn't currently support monorepos 😊
Ah I see - I would file this under "monorepo support". You might be able to get some mileage out of #509, but PSR doesn't currently support monorepos 😊
Thanks, that looks like a good solution to avoid writing custom parsers. I will add PR from that branch to add version_source from files
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
No update here, PR would be very desirable
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
As we have since deprecated and removed the version_source parameter in v8 the sole version identifier is tags. With this in mind while considering how to support monorepo constructs, I believe implementation for PSR will instead use tag prefixes as the version determinant as described in #579.
Closing this issue as the essence of this request will be handled in a different way but still meet the end goal.