GithubHelp home page GithubHelp logo

Comments (2)

primeos-work avatar primeos-work commented on June 26, 2024

Good idea. Butido currently lacks the concept of distros (s. also #185 (comment)) but IMO it's quite essential for a proper distro/OS independent package build tool to support distro/OS specific configurations.

I'm not sure how to best address this though. Distro specific build/runtime deps should be fairly easy to achieve but I wonder if that's enough as we might also need different configure/compile/etc. flags (depending on the distro), which would require a generic solution (that could ideally be used everywhere - but I don't (immediately) see a good solution for that with TOML files). However, as long as the only use case is to take a dependency from butido's package repo or the system, it should be possible to ignore the rest (although it'd make sense to then make the OS/system packages conditional as well).

Any concepts/ideas/suggestions what the usage should look like (TOML example)?
It might make sense to use regex patterns/matching to avoid potentially long lists.
We could theoretically also match against the container image names instead of additional OS information that would have to be added first.

Maybe something roughly like this?:

[docker]
images = [
  { name = "local:sles15-default", short_name ="sles15" },
  { name = "local:deb11-default", short_name ="deb11" },
  { name = "local:deb12-default", short_name ="deb12" },
]

---

[dependencies]
runtime = ["foo =1.2.3"]
build   = [("example =1.2.3", "deb*") ("bar =1.2.3", "sles15")]  

I haven't thought much about the design yet, that's just the first thing that came to mind. Unfortunately TOML doesn't support tuples so we have to think of a proper design anyway (the tuples could be replaced with inline tables, which should make it easier to read and understand (for outsiders/newcomers) but the "code" would be longer (character count) and probably more annoying to write).
We should also try to keep the design backward-compatible (in my draft above "foo =1.2.3" could expand to ("foo =1.2.3", "*") so that users aren't required to change almost all of their files in the packages repo.

from butido.

primeos-work avatar primeos-work commented on June 26, 2024

Distro specific build/runtime deps should be fairly easy to achieve but I wonder if that's enough as we might also need different configure/compile/etc. flags (depending on the distro), which would require a generic solution (that could ideally be used everywhere - but I don't (immediately) see a good solution for that with TOML files).

Brief update: Due to additional customization requirements and the constraints of TOML, we decided to try this out via a preprocessor (and if it works out well, we could theoretically integrate (parts of) it into butido).

from butido.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.