pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
little_blossom has quit [Quit: little_blossom]
little_blossom has joined #openscad
<Scopeuk>
Looking good
califax has quit [Remote host closed the connection]
califax has joined #openscad
mohammad1722 has quit [Ping timeout: 250 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
hyperair has quit [Ping timeout: 252 seconds]
hyperair has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
J24k has joined #openscad
califax has quit [Remote host closed the connection]
mohammad1722 has joined #openscad
califax has joined #openscad
<mohammad1722>
How should the library manager resolve version ranges?
<mohammad1722>
Many library managers use a naive algorithm to resolve the latest version satisfying the constraints.
<mohammad1722>
Another solution I've been reading about is using a SAT Solver that would consider the full graph and try to find a dependency combination that satisfies all the constraints.
<kintel>
mohammad1722 One big question is to what degree we can trust semantic versioning for libraries, so pinning might become more important than range resolution.
<kintel>
It's also possible that questions like these may become easier to answer once we have a working prototype
<kintel>
Btw., what timezone are you in? I'm in EST (Eastern North America)
<mohammad1722>
Does library developers not follow semantic versioning? If not can we mandate if the devs want to use the library manager to use semantic versioning?
<mohammad1722>
I'm in Egypt currently timezone is UTC+3
mohammad1722 has quit [Quit: Client closed]
<pca006132>
I don't think SAT solver is a good way... to get to that level of dependency hell you need to download multiple versions of each library and get a graph of that...
<pca006132>
and I doubt if users really meant to specify very precise range of library versions
<Virindi>
it sounds like pretty soon we will be making openscad venvs
<InPhase>
kintel: Degree of trust in semantic versioning's ideals varies wildly by which subculture of programming the authors of those libraries are embedded in. I was just in a conversation the other day about how this is almost entirely absent in Python, where breakages on minor releases are considered a norm.
<InPhase>
kintel: There it is accepted to break on minor releases for "good reasons", with a very flexible choice of what counts as good reasons.
mohammad1722 has joined #openscad
<Virindi>
with python, if I clone a project, it only works for a week. after that something has broken it. especially the case with AI stuff
<Virindi>
might even be days
<Virindi>
somehow people consider that "normal"
<InPhase>
Part of this arises irreparably because of the high interdependencies of packages, so a minor release of one package might depend on a major change of another package, all along a tree of dependencies, and so it promotes the notion that nothing can be done to prevent the issue anyway.
<InPhase>
Virindi: People typically address that with "freeze until you're ready to fix".
<Virindi>
and some developers attempt to fix the issue by including a huge list of exact library versions, which causes the entire project to not work because one library is too old to support your hardware
<Virindi>
yes I address it with the philosophy of "never update"
<Virindi>
:)
<InPhase>
Virindi: Yeah, or worse, you have two dependencies which decided to depend on incompatible versions.
<Virindi>
in AI, every single time you update you have to create a new venv
<Virindi>
and you have a 20% chance of that version just being impossible to run
<Virindi>
it is frankly a nightmare and nobody cares, everything being broken is just expected
<InPhase>
Virindi: Fortunately I have been doing my LLM work with llama.cpp and avoiding this. I only tend to hit that problem you describe for unimportant things like my day job. ;)
<Virindi>
try using diffusers :D
<Virindi>
huggingface stuff is the absolute worst
<InPhase>
Cumulative experience though has taught me that semantic versioning is, on average, meaningless when interdependencies strike. So I take a "stop pretending" view, and advocate for date-based versioning which actually has benefits of usable information in the version numbers, so that one can look at a list of them and discern the mutual alignment of things on a common axis.
<Virindi>
yes, accurately labeling which versions work is too difficult a task.
<InPhase>
I'm all the time taking semantic version numbers, googling for that and "release date", and then desperately trying to find a page that actually HAS that date.
<InPhase>
Because this is the information I really need in order to sort out problems. Dates are the real semantic information.
<InPhase>
If all packages did date-based versioning, looking at lists of them would be so much simpler to process meaningfully.
<Virindi>
any system which does not rely on manual labeling would be better. for example, a release could have an attached db of library version combinations which work, the first one being the combination the developer used to build it
<Virindi>
if someone else built successfully using a different combination, that could be added to the database
<Virindi>
perhaps everytime someone builds it, it tries a slight variation of a known build also, to add to the db :)
<Virindi>
of course such databases would inherit
<pca006132>
ah
<pca006132>
dependency handling in AI stuff sounds really bad
<pca006132>
I rarely encounter this kind of dependency hell
<pca006132>
(I don't use many libraries anyway)
<pca006132>
I think alternatively one can think about using different versions of the library in different repo, we are not C, so we don't have to care about symbol naming
<pca006132>
and we don't have global states
<pca006132>
e.g. libfoo depends on libbar 1.0, libfoobar depends on libbar 2.0, we can depend on both libfoo and libfoobar, each using different version of libbar
<mohammad1722>
pca006132: How do you ensure that libfoo will use files from libbar 1.0 and not libbar 2.0?
<pca006132>
this requires modifying the evaluator
<pca006132>
will be painful, but not impossible
<pca006132>
what I was thinking about is mostly semantic issue, not "difficulty of implementation"
<pca006132>
i.e. just brainstorming
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
L29Ah has left #openscad [#openscad]
molls has joined #openscad
molls has quit [Client Quit]
mohammad1722 has quit [Ping timeout: 250 seconds]
kintel has joined #openscad
L29Ah has joined #openscad
mmu_man has quit [Ping timeout: 256 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]