#Depedancy Discussion

1 messages · Page 1 of 1 (latest)

worn smelt
#

Thread

ornate sandal
#

🧵

south creek
#

🪡

worn smelt
south creek
#

so if we stick to CNF in dependencies [a,b|c,d -> a and (b or c) and d] and treat conflicts separately as each entry negated, that still means they would be fundamentally chained with OR

#

right?

worn smelt
#

No they would be fundimatally chained with and

#

if one fails it fails to load

south creek
#

but that and means or

#

in terms of non-load conditions

worn smelt
#

Alternative idea

#

we get rid of more complicated thingas

#

and do an array for the main operator (AND for deps, OR For anti deps)

#

and then the other dep is just in that

ornate sandal
#

NOT (a OR b OR ...) for anti deps right

south creek
#

so something like dependencies: [ "A", "B>=2|C", "D<=2"], conflicts: ["E,F>=1", "G"]

worn smelt
#

so json { "Deps": [ "Talisman>=1.0", "Steamodded>=1.0~", "Steamodded>=1.0~beta-9999a OR AlternativeDep>=1.0", ], "Conflicts": [ "Cryptid<=1.0" ] }

#

Not sure exactly what do for an and in conflicts

#

the OR is subject to be changed

south creek
#

where that means the mod conflicts with the combination of E and F>=1 and also conflicts with G

south creek
worn smelt
#

Possible even a sub array

#

idk if that would get too confusing

south creek
#

I think with this solution, | for alternative deps and & for chained conflicts

worn smelt
#

Do we even need chained conflicts?

south creek
#

maybe chained conflicts are just stupid

#

if you can't load if both A and B are present but are fine with either one on its own, what are you doing

worn smelt
#

Would they be useful for conflicting with a version range for a conflict

#

like if I want to conflict with versions >=2.0 and <3.0

#

how would I do that?

south creek
#

can't I just supply a version range like "Cryptid>=2.0<3.0"

worn smelt
#

hmm didn't think of that

#

that would make sense

south creek
#

that's how this has been working with dep strings

#

except we don't have strict inequalities

ornate sandal
#

I'd prefer to write it as 2.0 <= Cryptid < 3.0 but sure

worn smelt
#

Cause I think conflicting only if 2 packages exist is kinda silly

south creek
#

cut that part, not sure what I was thinking that was useful for

worn smelt
#

Maybe a way for mods to show up as failed to load in thier code (assumingthey haven't registered anything yet)

#

So this is what we are thinking for syntax? JSON { "Deps": [ "Talisman>=1.0", "Steamodded>=1.0~", "Steamodded>=1.0~beta-9999a | AlternativeDep>=1.0", ], "Conflicts": [ "Cryptid<=1.0", "DebugPlus>=2.0<3.0" ] }

#

also possible alternative json { "Deps": [ "Talisman>=1.0", "Steamodded>=1.0~", [ "Steamodded>=1.0~beta-9999a", "AlternativeDep>=1.0" ] ], "Conflicts": [ "Cryptid<=1.0", "DebugPlus>=2.0<3.0" ] }

#

I feel like thats not clear enough

south creek
#

that looks confusing

ornate sandal
#

first one is clearer

worn smelt
worn smelt
#

Maybe we should do a debain and do json { "Deps": [ "Talisman (>=1.0)", "Steamodded (>=1.0~)", "Steamodded (>=1.0~beta-9999a) | AlternativeDep (>=1.0)" ], "Conflicts": [ "Cryptid (<=1.0)", "DebugPlus (>=2.0) (<3.0)" ] } (Not sure how to handle the last case)

#

oh wait thats the wrong base example

#

Edited

ornate sandal
#

I'm still not a huge fan of chaining the version relations like >2.0<3.0

#

though the brackets help

worn smelt
#

The issue is parsing 1.0 < pkg is a lot hearder to parse

#

cause now we got to figure out if 1.0 is a id or version

#

I guess brackets still help here

#

but then it's still a bit more complicated

#

Also since we need to parse this

ornate sandal
#

fair

worn smelt
#

what is allowed in version string and id strings

south creek
#

if we do brackets, neither are allowed brackets

worn smelt
#

I propose [A-Za-z0-9._~-] for both

#

(although I also purpose % or smth be allowed to be the first char for internal id's only)

ornate sandal
#

don't forget the .

worn smelt
#

right

south creek
#

parsing the versions without brackets works alright, I still think I prefer them

worn smelt
#

I think I prefer them too

#

it's much easier to see whats version and what's not

worn smelt
#

It would just be prohibited in the id and the provides

ornate sandal
#

as of now that's only balatro and lovely right (possibly steamodded?)

worn smelt
ornate sandal
#

yeah

#

and <, >, >=, <=, == for the operators?

worn smelt
#

potential to prohibit any characters that can't be indexed like SMODS.Mods.IDGOESHERE in the id

worn smelt
worn smelt
ornate sandal
#

could also do != instead of ~=

worn smelt
#

do we need a not eqal?

south creek
#

I'd leave out not equal

worn smelt
#

Doesn't make sense for deps and for conflicts just depend that exact version

south creek
#

besides you could already do that with > and <

worn smelt
#

I did notice debain does << and >> for the < >

south creek
#

that's convenient because the operator is always two chars

worn smelt
#

yeah

south creek
#

I'd take that

worn smelt
#

also less likely for mistakes by typo

ornate sandal
worn smelt
#

Proposed operators A (>=1.0) - A greater than or equal to 1.0 A (<=1.0) - A lesser than or equal to 1.0 A (>>1.0) - A greater than to 1.0 A (<<1.0) - A lesser than to 1.0 A (==1.0) - A equal to 1.0 (would this also match 1.0.0? Would A==1.0.0 match A 1.0 as well?)

south creek
#

1.0 and 1.0.0 are internally the same version

#

unless you fill missing fields with -1

worn smelt
#

ok that makes sense to me

south creek
#

which we don't

worn smelt
#

I'm assuming 1.0 and 1.0~ don't match

ornate sandal
worn smelt
#

Should I ping mathisfun? I feel like he would have some potentially useful insite

ornate sandal
#

go for it

south creek
worn smelt
#

@jovial hawk got any thoughts?

south creek
#

in fact 1.0~ is the least version of major 1 and minor 0

worn smelt
#

ok good

#

but overall I'm happy with the proposed system now

jovial hawk
#

Why << and >> over < and >?

#

That’s really the only oddity I’m noticing so far

south creek
#

meanwhile I wrote up this conversion

image.png
south creek
worn smelt
jovial hawk
#

Yeah that makes sense

worn smelt
#

aka we're a bucnh of developer

south creek
#

a version can't start with = in our system so it's not actually ambiguous, just more annoying to parse

worn smelt
#

yeah I was mostly thinking about parsing

#

also I'd propose all white space is just ignored

ornate sandal
jovial hawk
#

What if we added an ===?

==1.0 matches 1.0.x, ===1.0 only matches 1.0.0

jovial hawk
south creek
jovial hawk
#

If they’re not using << or >>

worn smelt
ornate sandal
#

could also do it as >= 1.0 and < 1.1?

worn smelt
#

Well that matches 1.0.1

south creek
#

i think that's too confusing

worn smelt
#

Oh wait your suggesting it matches only the sub version

#

So you can match any 1.x.x

#

That might be worth considering

south creek
#

that would require 1, 1.0 and 1.0.0 to all be different versions internally

#

which they're not

worn smelt
#

Not what I'm suggesting

#

I'm on mobile give me a minute to get back to my dorm to type something up

south creek
#

imo that's too much work for something you can already do

worn smelt
#

The thought is some kind of operator where it would basically convert (newOperator A.B.C) to (>= A.B.C) (< A+1.0.0)

#

Oh also thought does <1.0.0 still match 1.0.0~

#

Also possibly the same op but (>= A.B.C) (< A.B+1.0)

south creek
#

ah

worn smelt
#

Mostly cause I suspect that a lot of people are just going to do >= version and then break when major version change

south creek
worn smelt
#

yeah that makes sense

#

Although it gets potentially messy if you want to support multiple major versions

#

Maybe we just well document what to do

ornate sandal
#

wait >= 1.0.0 wouldn't match 1.1.0?

worn smelt
#

no it does

#

The idea is if you want to match just 1.x versions we might want an operator to help with it

#

¯_(ツ)_/¯

ornate sandal
#

ah

jovial hawk
#

Wild card?

ornate sandal
#

could == 1.1 work for that?

jovial hawk
#

1.*

south creek
#

just had the same thought lmao

worn smelt
#

should we make (<= 1.0) and (<< 1.0) actually match 1.0~?

#

Cause I doubt most people actually want < 1.0

south creek
#

yes, that's how the ordering works

#

we just put in the docs that the wanted behavior is <<1.0~

worn smelt
#

sorry like behave like the user put 1.0~

#

well

#

I gues it would just be <<

#

<= would match as expected

#

Cause if I put << 1.0 I wouldn't expect 1.0~beta1 to match

#

and lets be honest people aren't going to read the docs they'll jsut look at a couple exaples from other mods

#

We could add some other thing to force the actuall 1.0

#

like 1.0! or smth

#

Yeah I can't think of any case where one would want to match ~ versions but not the main version they are based off of, other than if you just want to match the ~ versions

#

Maybe we could make << 1.0 behave as << 1.0~ and add a <~ or smth that behaves as << 1.0

split wave
#

surely they'd be the other way round, no?

worn smelt
#

well the behaviour I described for << would be the intended behaviour in most cases

#

so it would make more sense to me to make it the << operator

split wave
#

oh nvm I am dumb and forgot ~ is for pre 1.0

south creek
#

it seems this works for the most part

image.png
#

just need to make sure I didn't break stuff by allowing major-only versions

#

i did find this which is a bit weird

image.png
worn smelt
#

I think tralining .'s shouldn't be allowed

south creek
#

I would have kept it that way if I could just use regex

#

i can't figure out how to do that with a lua pattern

#

maybe some string.gmatch can help

worn smelt
#

how strict are we on the spec?

#

cause you could just require %d+(\.%d+(\.%d+)?)?[-~]

#

I probably messed that up somehow

#

I guess that wouldn't work with balatro's versions as it has a letter right after the last number

south creek
#

I'm not sure lua patterns can even nest captures

worn smelt
#

try it

#

Also I think nesting is optional in this case

south creek
#

rn I'm at ^(%d+)%.?(%d*)%.?(%d*)(.*)$ which is definitely not restrictive enough

worn smelt
#

put the .'s in the capture group for the mnumber they go with

#

will have to do some more work to remove it from the group but thats another simple pattern

#

unless it supports non-captruing grouops

south creek
#

it doesn't

worn smelt
#

Oh this will be handy once you get to the bracket part

image.png
south creek
#

oh i don't need this, we don't support nested brackets

worn smelt
#

oh true

#

also sub captrues are supportedf

south creek
#

i can't make it work

#

maybe because I'm too braindead for it at 12:30am

worn smelt
#

regex at 12:30 is never a good idea

south creek
#

i would not mind at all if it were regex

#

but it's not

worn smelt
#

almost regex at 12:30 is never a good idea

south creek
#

anyways I pushed what I have up to a temp branch

#

if anyone wants to fix the version string pattern, be my guest

#

because I shall go to sleep

#

also the dependency checker might need some further testing for I won't trust code I wrote past midnight

worn smelt
#

I might be stupid

#

can't figure out how to print the captures

#

I'm doing

# 
eval for m in string.gmatch("1.0.1", "^(%d+)%.?(%d*)%.?(%d*)(.*)$") do
    print(m)
end```
#

but its not priting anyrthing

#

ok wtd

# 
for m in string.gmatch("1.0.1", "(%d+)") do
    print(m)
end
``` prints something but ```lua
for m in string.gmatch("1.0.1", "^(%d+)") do
    print(m)
end
``` doesn't
#

oh I can string.match

#

can't make groups optional

#

thats annoying

ornate sandal
south creek
#

oh, that's what went wrong

worn smelt
#

you can detect the trailing dot and then just erorr manually

#

like my (WIP) pattern ^(%d+)(%.?(%d*))(%.?(%d*)) you get two groups for the digit so if one is empty and one isn't its an error

#

so you can detect the traling dot in the last case

#

Here it is with the rest

image.png
#

I'm assuming we stick the last group through another regex

#

^(%d+)(%.?(%d*))(%.?(%d*))(.*)$

worn smelt
#

aure are you still awake?

#

if it fails to be valid should it throw and error?

worn smelt
#

oh I posted two sets of them in the scvreenshot

#

I'm assuming we want to parse this as it has

#

I'll push my test setup so you all can use it to

upper stratus
#

let me know if you guys need any help, I've got experience with this sorta thing

worn smelt
#

want to take a look over our proposal as is rn

upper stratus
#

my general heads up is that the more feature-filled dependency resolution becomes the slower and more complicated it gets

worn smelt
#

makes sense

upper stratus
#

if you want version ranges and incompat then I 100% recommend implementing this as a directed graph

#

you can do a graph traversal to determine your dependency set AND do advanced analysis on the graph

worn smelt
#

oh no data structures and algorithms my only weakness

upper stratus
south creek
#

for deps it should at least give a warning

south creek
#

I'm already using DFS so I'm not gonna rewrite just because

south creek
#

wildcards are in

image.png
#

wait should 1.* match 1.0~?

worn smelt
#

Also you should mess around with the test file cause I need to force people to test stuff for me

south creek
#

hm yeah

south creek
ornate sandal
#

I think it should yeah

#

Though it depends on how the GT and LT operators treat it

worn smelt
south creek
#

if no, what wildcard is supposed to match it?

worn smelt
#

great question

#

see the issue is if I specify I want a 1.* version and geting a prerelease 1.0 version is almost never what I want

#

steamodded is the big exception

#

maybe 1.*~

south creek
#

(==1.*) (>=1)

worn smelt
#

hmm

#

maybe 1.* matching 1.0~ is fine

#

cause it would make sense to match 1.1~

south creek
#

yeah that's my other concern, this is confusing and inconsistent

worn smelt
#

I'm almost worndering if maybe we should never match a ~ build unless the user manually specifies

#

and then allow appending ~ as a shorthand to match any ~ version as well

#

I'm just thinking index wise auto downloading beta versions is a bad idea

south creek
#

hm

worn smelt
#

I know in my case beta versions are not goign to always match the api of a full version

south creek
#

this has no correlation (yet) to how the index would auto download versions

worn smelt
#

well it does somewhat

#

I think it would be fair to say >= 1.0~ will match all 1.0 versions inclduing beta

worn smelt
south creek
#

yeah that's what I was just thinking

worn smelt
#

I think a ~ without any content should have special meaning

#

make it where a real version can't have it

#

but when resolving deps it will match any beta version

#

not sure should (== 1.0~ match 1.0)?

south creek
#

no

worn smelt
#

okay

#

should (<= 1.0~ match 1.0 then)

south creek
#

no

worn smelt
#

ok makes sense to me

south creek
worn smelt
#

looks good

#

was just thinking if we did want empty ~ we could also allow wildcard ones

south creek
#

should (<<1.1) and (<=1.1) match:

  • 1.1~x
  • 1.0.1~x
worn smelt
#

I'm thinking no

south creek
#

what about (<<1.1~) and (<=1.1~)

worn smelt
#

I'm thinking yes

south creek
#

technically 1.1~ would be the least 1.1 version

worn smelt
#

I think this should be a special case

south creek
#

but since this matches all beta 1.1s, this makes sense

worn smelt
#

I think it's basically a beta wildcard

#

also we haven't talked about the - things

south creek
#

there's no difference between <<1.1~ and <=1.1~ then?

worn smelt
#

you know what thats a good point

#

Is there a difference between <<1.* and <=1.*?

south creek
#

technically I have not considered wildcards for use with << at all

worn smelt
#

we're treating just ~ as a wildcard basically

south creek
#

Im referring to * as wildcard here

worn smelt
#

yeah I know

#

but the way we are making ~ is basically a wildcard

south creek
#

<<1.* would behave like <<2 so it's fully redundant

#

so is <=1.*

#

arguably we only need to allow * for use with ==

worn smelt
#

yeah

south creek
#

=1.* is just >=1, while >>1.* is >>1

worn smelt
#

yeah

#

but do we support them?

south creek
#

lemme see

#

I didn't account for * wildcards in strict inequalities

#

1.* is represented as 1.-2.0, so <=1.* is actually equivalent to <<1

worn smelt
#

that doesn't make much sense

#

I could see <<1.* being equivalent to <<1

south creek
#

that is also true

#

again there's no need to support these

ornate sandal
#

Agree with Wilson, <=1.* shouldn't exclude 1.*

south creek
#

I think I'd still prefer if they made sense

worn smelt
#

yeah it does seem odd having a version that can only be represented with one operator

south creek
#

pretty sure that can be made work

#

not too sure on what <<1.* should mean still

worn smelt
#

I think it should just be the same as <<1.0

south creek
#

if * represents "all applicable versions at once", it should just mean <<1

#

likewise >>1.* should refer to >=2 then?

worn smelt
#

yeah

#

that one I can see making sense

#

cause if your like a need a version higher than version 1

south creek
#

so >=1.* means >=1 because ==1.* does that and >> is a subset of it

worn smelt
#

yeah

south creek
#

likewise <=1.* is like <<2

worn smelt
#

yeah

ornate sandal
#

Makes the most sense to me yeah

south creek
#

and all of this can only ever match if beta-ness is equal, or do we have exceptions to that?

worn smelt
#

Yeah I think so

#

well

#

I think the range one;s with beta may match non betas

south creek
#

yeah right

#

but if >=1.0~ matches non-betas, by extension <=1.0 must also match betas

#

else we don't have a well defined relation

worn smelt
#

idk

#

ok fine I guess 1.1~beta can match >= 1.0

#

but I think >=1.0 won't match 1.0~

south creek
#

=1.0 doesn't match betas, that's not what I said

#

I'm saying if >=1.0~ will match 1.0, then <=1.0 must match 1.0~beta

worn smelt
#

I don't reaslly like that

#

actuaslly

#

I guess for an equality it's fine

south creek
#

else it's not really an ordering at all and operator overloading can't handle it

worn smelt
#

<= is a silly operator

south creek
#

idk

ornate sandal
#

since this is for dependencies, I don't think you should match betas unless specifically required

worn smelt
#

I was thinking that

#

but also chances are 1.0.1 beta is fine for use with >=1.0

ornate sandal
#

as a user, I'm not sure I'd expect a beta to be installed when using >= 1.0

south creek
#

a 1.0.1 beta likely doesn't have breaking changes from 1.0.0 stable

worn smelt
#

yeah I figured the same

#

although technically a 1.1.0 beta could behave differently than 1.1.0 stable

#

cause the feature thats added may change betwene the two builds

south creek
#

hence why (>=1.1) does not include any 1.1.0 beta (or any beta at all, for that matter)

#

but (>=1.1~) might include a 1.1.0 stable and a 1.1.1 beta

south creek
#

if (==1.*~) matches all 1.x including betas, (==1.0~) should match all 1.0 including betas

#

alright I think I got it down

image.png
#

who needs a total ordering anyways

#

would appreciate some more testing on this

#

I'll add some of the other stuff like a config file name, icon atlas metadata and making provides usable with this, then we'll be pretty much set for a beta release with this merged