Replies: 2 comments
-
|
Hello, thanks for bringing the discussion. My impression of these issues has mostly been around:
(Maybe also ergonomics about running things in a project as well?) Does that resonate with your concerns? Separately I have worried about this:
Since bramble is structured to use packages that people host publicly and not a central package tree I worry about duplication. You could import 6 different versions of libc when grabbing a handful of packages. Ideas around solving this so far mostly revolve around either "have a good standard library" to "write tools to help people analyze these kind of issues". Would be great to see examples of what you're talking about if possible. Yes definitely hoping to get a good language server working. Linting and formatting all the way as well. And generally, need to dogfood more to start getting closer to some of these problem spaces. It's early days. |
Beta Was this translation helpful? Give feedback.
-
|
I think deduplication is a natural part of package management by the community - people making PRs to update dependencies to other bramble definitions to reduce deps. People forming their own groups of pointers to definitions or sets of definitions they like or tested or whatever. For a more formal peer into quality control for distributed definitions, https://web.crev.dev/rust-reviews/ could be used as some inspiration. +1 on having tools that can
Content-addressable dependencies are great! I think some packages will be more able to handle this than others if they already support reproducible builds. Maybe packages can define what is included in the hash to match, to avoid situations like 'one was build with |
Beta Was this translation helpful? Give feedback.
-
One of the surprises I have seen crop up with nix in the wild is, for lack of a better phrase, every setup being special.
Three different friends of mine have shown their nix setup for similar projects, and all were wildly different in
What is most frustrating is every author claiming 'this is idiomatic nix' or 'this is the correct setup for nix'.
This makes it difficult to navigate in new projects, as you can effectively split up expressions into as many or few files as you'd like.
There is rarely an 'atomic' unit or obvious place for new contributors to modify or model their own derivations - the default I've seen is 'import some other expression then override what you need'.
It increases the amount of investigation and reading, following the breadcrumb trail to be sure of what is actually being run. It decreases my trust in being able to open an file and understand all of its effects until grep'ing every single definition.
It reduces the amount of transferable knowledge, such that investment in understanding a nix-based project or derivation rarely pays dividends when looking at another project.
I don't have any real solutions, just wanted to start the discussion and thinking around how bramble may consider the impact of design decisions on flexibility vs. obviousness, DRY versus keeping remote state in your head, etc.
Some issues may be non-issues since bramble chose Starlark as the language. For example, I expect language server to have go-to-definition instead of me having to grep and hope i'm looking at the right place.
Some issues may be avoided with linting and formatting tools.
Some may motivate experimental restriction, for example restricting import depth.
The whole premise of this discussion could be a non-issue if bramble has different priorities of power vs readability.
I already think its a great idea to have the software describe how to manage itself, which may go a long way to reducing these theoretical issues. Anyway, thats enough rambling for now.
Other software management systems I have contributed to have not had the issues outlined above to the same degree. This is expected as they had different restrictions and goals - in general they are less reproducible / compartmentable.
For disclosure of my biases, I have been a package maintainer or contributor for gentoo (ebuilds), exherbo (exheres), debian, nodejs (npm), kiss (files), clojure(script) (lein and boot), homebrew (formulas / casks).
Beta Was this translation helpful? Give feedback.
All reactions