question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[question] requirements versions in yml?

See original GitHub issue

Currently, dependencies versions are hardcoded in conanfile.py For most recipes, it plays well whatever the library version.

But I’m trying to package Vulkan-ValidationLayers. It has 3 dependencies:

  • Vulkan-Headers
  • glslang
  • SPIRV-Tools

Vulkan-Headers is not backward compatible. The version of Vulkan-ValidationLayers is tightly coupled with Vulkan-Headers one. glslang and SPIRV-Tools seem to be backward compatible (not sure, but I was able to build “old” versions of Vulkan-ValidationLayers with recent versions of glslang and SPIRV-Tools).

Even if Vulkan-ValidationLayers and Vulkan-Headers follow more or less the same versionning, there is not always a perfect match.

Here is an example of what I could use in conandata.yml:

requirements:
  "1.2.135.0":
    - name: "glslang"
      version: "8.13.3559" # not compatible, missing members in spv namespace
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.2.135.0" # strict requirement
  "1.2.131.2":
    - name: "glslang"
      version: "8.13.3559"
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.2.131.1" # strict requirement, there is no 1.2.131.2 for vulkan-headers
  "1.2.131.1":
    - name: "glslang"
      version: "8.13.3559"
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.2.131.1" # strict requirement
  "1.1.130.0":
    - name: "glslang"
      version: "8.13.3559"
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.1.130.0" # strict requirement
  "1.1.126.0":
    - name: "glslang"
      version: "8.13.3559"
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.1.126.0" # strict requirement
  "1.1.121.0":
    - name: "glslang"
      version: "8.13.3559"
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.1.121.0" # strict requirement
  "1.1.114.0":
    - name: "glslang"
      version: "8.13.3559"
    - name: "spirv-tools"
      version: "2020.1"
    - name: "vulkan-headers"
      version: "1.1.114.0" # strict requirement

In this example glslang and spirv-tools could be hard coded in conanfile I guess, but not vulkan-headers.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:1
  • Comments:9 (9 by maintainers)

github_iconTop GitHub Comments

1reaction
jgsogocommented, Feb 8, 2021

This is interesting, but it can get complicated. Maybe there are different version ranges for different configurations or OSs. For example, if you activate option XXX that enables some feature then you will use a different version range… and this is not tractable in a declarative way (it can become hard).

This declarative way could serve most of the cases, but not all. Still some checks will be hardcoded inside the recipe when they depend on configurations. Do we want it only for some references?

Maybe all we need is some kind of tool and write:

def validate(self):
    tools.validate_semver(self.deps_cpp_info['req1'].version, '>=8.13.3559')

IMO, it is quite straightforward for recipe authors and readers, and it covers all the use cases, it can be very specific about the configurations the check applies to…

One missing use-case though, the one I talked to you about: the bot that tries to upgrade the version of requirements as soon as they are available. This scenario is a bit different, as the bot will try a version of the requirement and try to build the packages for all the configurations, if any configuration fails, that version will be forbidden to the bot (but it might work for a user using a specific configuration). I mean, the version_range won’t be the same for consumers and for the C3i-bot and probably they shouldn’t try to share the same storage.

1reaction
SpaceImcommented, Apr 20, 2020

It appears that, among all history of releases, there is only one version of Vulkan-ValidationLayers which requires a different version of Vulkan-Headers than its own version. Thereby it’s acceptable to do something like this:

    def requirements(self):
        self.requires.add("glslang/8.13.3559")
        self.requires.add("spirv-tools/2020.1")
        self.requires.add("vulkan-headers/{}".format(self._get_vulkan_headers_version()))

    def _get_vulkan_headers_version(self):
        return {
            "1.2.131.2": "1.2.131.1"
        }.get(str(self.version), str(self.version))
Read more comments on GitHub >

github_iconTop Results From Across the Web

Version in requirements.yaml - kubernetes helm
In general there is no support to parameterize requirements.yaml. Also refer to the official helm documentation for requirement files.
Read more >
Cannot apply uploaded requirements files or ... - Microsoft Learn
When trying to import python libraries at a spark pool level by appying an uploaded requirements.txt file, I get the following error:.
Read more >
Configuration File V2 - Read the Docs
Configuration for MkDocs documentation. ... If you want to pin MkDocs to a specific version, use a requirements.txt or environment.yml file (see Requirements...
Read more >
YAML - Wikipedia
YAML (see § History and name) is a human-readable data-serialization language. ... VersionsEdit ... Strings do not require quotation marks.
Read more >
10 YAML tips for people who hate YAML | Enable Sysadmin
If your problem is YAML, and you're having a difficult time visualizing ... with the requirements for valid YAML spelled out with lots...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found