one last rant on this for now.
to me, your JS example illustrates almost the exact opposite point. if i build a web app that uses jquery, i will either serve the minified lib myself, or pull a specific version from their CDN - effectively the same thing as using a local copy. (regardless of whether its cached in the browser, on my server, on their server, on disk, whatever, the principle is the same: the app writer has complete control over the libraries that are served; they aren’t just pointing at “the latest version” of the lib, b/c that’s how stuff breaks. it’s why jquery &c have strict semantic versioning and multiple versions hosted all the time.)
just look at the panoply of versioning management and deployment tools built up in javascript world around managing library dependencies; it’s complex.
still, something like that would be fine here, and is totally fine for “engine libraries” - by which i guess you mean the lua ‘helpers’ that wrap parameters for passerby, &c - or for any other libraries that are pure lua. the analogous strategy here would be for your script repo to pull in a submodule - which is effectively a copy of the source library frozen at a specific version - precisely analogous to pulling a specific lib version from a CDN, with or without a deployment/packaging tool.
(again: i kinda pushed for not having .sc classes in “third party” repos, precisely so that people could have more flexible deployment strategies for dependencies. but it’s a tradeoff b/c then you have potentially tightly coupled components in different locations! there is no clear way out of that.)
the only real “difference” is that we simply don’t have fine-grained and dynamic control over where SC looks for class definitions, so we just can’t do something like that for actual .sc classes. (without more work.) it is definitely a bummer. [*] i outlined two strategies for dealing with that above. there’s a third approach which is switching from requiring all SC code in .sc classes to providing “factory” classes that you customize at runtime instead of compile time. all three are on the table for the next major update. all three are heavy changes that we should undertake only with due consideration of actual issues - not hypothetical ones.
this update is mostly focused on 1) the jack client changes (which are huge), 2) getting people used to hosting their own scripts, and 3) some huge improvements to stability of infrastructure like networking, which makes everything easier and gives us the freedom to make more seamless file management tools in 2.x.
again, if script writers are only using existing engines, or only making their own engines, none of this is going to be any kind of issue whatsoever.
for now i would love to get on with making stuff. i think this wlil be quite usable in the short term; we have i think a fine understanding of the pitfalls.
[*] i want this to be crystal clear, so here’s another example: i write a script using engine Foo that someone else wrote. it’s defined in Foo.sc.
option A: Foo.sc lives in a central location/repository, like dust/code/we/lib. it’s in the SC path.
- bonus:
Foo is always available.
- malus: monome has to manage versions of foo.
- malus: i have to be aware if there are changes to the
Foo API and update my script accordingly.
option B: Foo.sc lives in dust/code/fooguy/lib. since fooguy/lib is in the SC path too… hey! there is no difference to the script writer! the only difference is that the decision to includefooguy is up to the user, not monome. this is what we’re doing right now.
- bonus: monome doesn’t have to manage versions of
Foo.
- malus: the user might not have
Foo installed; you have to warn them. in practice, i don’t think this is gonna matter, b/c we’ll be rolling popular engines into ‘upstream’ channels.
- malus: i have to be aware if there are changes to the
Foo API and update my script accordingly.
with either option, you can always make FooBar.sc. it is deeply unfortunate that you can’t just “deploy” your own copy of Foo.sc into your project path, updating it with new versions as you please. this would solve all our complaints and be more “javascripty.” but for now, we can’t do that; it’s a limitation we have to work around, that’s life.
i want to make one important point (responding to @junklight): off the top of my head, i’m not aware of any actual changes that need to be made to engine code for 2.0. the SC engine API is presently entirely backwards-compatible. this was on purpose; if we wanted to break it we could do all kinds of fancy stuff. so if an engine author doesn’t want to self-host, we can just leave that engine in we and everything depending on it should continue to work.
(and indeed, there was a temptation to break it early, since there are only like 10-20 engines right now; but we wanted to get the update out sooner rather than even later, to take advantage of new features, stability, and performance.)
