Allow creation of BOM dependancies #8251
Comments
cloutierjo
added
kind/feature
|
what is BOM? I don't know what you're talking about! This sounds as though it is probably duplicate #7051 |
|
Clearly not a duplicate given the last few comments on that issue. It mean Bill of materials, but here is a description coming from maven https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms and gradle https://docs.gradle.org/current/userguide/platforms.html. also a good article on the detailed benefit from it https://blog.mrhaki.com/2019/04/gradle-goodness-use-bill-of-materials.html?m=1 The main distinction i see between both issue is that 7051 look at final user (the one running the software) being able to decide which dependency get installed, while this one give project developer a curated list of dependencies version that can be used. In the end maybe the same solution could be apply to both, but I doubt it as here it should be specified in the pyproject files while it look like in 7051 it should not impact it as they don't own the project and this should be added as command line parameter. |
|
but that doesn't seem to have anything to do with what you are talking about? so far as I can see what you are asking for is the same thing as what #7051 is asking for: which is to say transitive dependencies that aren't necessarily installed but nevertheless act as constraints, much the same as pip's notion of constraints. Please clarify what you think is different. |
|
I might have edited my previous answer after you read it. But my feature request is summarising the concept of bom similar to the maven one so not sure how it's not related? |
|
let's not get bogged down in what BOM means to each of us: do I understand correctly that you are asking for a way to express transitive dependencies that aren't necessarily installed but nevertheless act as constraints, much the same as pip's notion of constraints? that would be a duplicate of #7051 |
|
No I'm asking to constraint explicitly expressed dependencies based on version constraints managed outside the project usually outside the development team. Also, i did look in pip constraint and it didn't really solve this but I would need to look back at the documentation to properly remember why. |
|
I'm pretty sure that this is close enough to #7051 that you should be getting involved there, rather than treating this as a separate thing. It's not like that one has reached a plan or anyone has shown up who looks likely to implement it: much better to try and steer it in a direction that works for you in the event that anyone ever does pick it up. (What you're saying still sounds to me exactly like #7051! but if there is some subtle distinction then it seems likely to be more usefully written down as part of the same conversation) |
|
The fact that the other one is not moving forward is a reason why I open it as a separate issue, because i really believe this can be solved quite easily but clearly won't solve the airflow issue, but sure i can repeat it there and get feedbacks from people's involved. |
as this issue tracker demonstrates, the usual result of this reasoning is two issues that are not moving forward... Issues progress when someone shows up who is able and motivated to progress them. If you care about this and believe that it is easily solved - submit a merge request! |
I understand this doesn't work because only the main dependencies of a dependency are considered during dependency resolution.
Doesn't this already work as expected? I don't understand what is missing to satisfy your use case. Dependencies of the optional bom group are considered during dependency resolution but not installed by default because it's an optional group. If they are addionally requested by another (non-optional) group (or a dependency of a non-optional group) they are installed by default, of course. |
|
Maybe it changed, but I tested a couple weeks ago and while the direct dependency in the optional group is resolved and affect what get locked, the transitive dependency from that project where not resolved unless the group was selected for installation. I'll give another try (probably on Monday) as you created a doubt in how I tested it and maybe your right |
|
sbom is the common parlance re sw, and then its a format discussion (cyclonedx vs spdx), ideally could be handled via a plugin, but also fwiw, most sbom tools already can handle poetry formats. |
|
suspect this should just be closed: OP not coming back can likely be interpreted as "oops, this is fine all along" |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Although it might relate to Support for "soft" or suggested constraints #7051, but the goal seems different (they target runtime, while I'm really more on the development/build part)
Feature Request
BOM dependencies allow to depend on a specific project that would limit the dependencies on our own project. BOM dependencies do not act as transitive dependencies as they wouldn't be installed unless explicitly defined in our current project or in its resoled transitive dependencies. For that matter, it would behave a bit more like the constraint file from pip, but has to be pulled like a dependency instead of being directly fetch from an uri.
I had great hope when I saw the optional dependencies feature come out, as that could bring BOM like features in a very easy way to poetry. I see two ways of making it work using optional dependencies:
resolve optional transitive dependencies
The idea would be that when resolving dependency version, the optional dependencies version rules defined in one of our project dependencies (our BOM dependency) would be checked to do the version resolution that will end up in the poetry.lock
In practice, that would mean in the BOM project we would define an optional group dependencies with all the version rules applicable. The in our project we would add a dependency on the first project, then the dependencies to all requirements for our project. The version could be as simple as '*' if we delegate everything to the BOM, or we could add our own version rules which the resolver would need to solve like any regular transitive dependencies.
resolve optional dependencies' dependencies
instead of having the BOM project define the optional block, it would be the project that would define it as optional. Thus all transitive dependencies from the bom project should be used in the project resolution, in the same way as directly written dependencies are taken into account in resolution as stated by the doc
So in practice, the bom dependencies would only be a normal project defining requirements. and our project would define its own requirement as usual, but adding the constraint of the transitive dependency on the BOM project:
I feel the first solution would better address the goal of BOM dependency, but the second one might be closer to be usable in poetry in the current state.
In the end that kind of feature would make it a lot easier to keep uniformized dependencies across multiple projects managed by the same teams. Would also allow defining a "good stack" for large framework (although not much an issue in python). It would also help conformity when dependencies have to be approved before being used in a company.
The text was updated successfully, but these errors were encountered: