Quark Versioning / Dependency Management

[semiquaver]

@julian

the typical entity that is distributed in a community is a small piece of text, rather than a file or even a folder

…but perhaps this is largely because currently distributing larger projects is almost impossible!

@julian

first implement the dynamic extension of the class library. As far as I know, the current method table could be replaced by a hash table, which can be extended.

Yes! This is important for many reasons.

@scztt

• Specify a way to call out dependencies in a floating .scd file - i’m imaging a blog of yaml in a comment at the top, that mirrors the format of the Quarks dependencies field. This would act like a standalone quark in a single file.
• Add a method to inject your current deps list into the current scd file - or e.g. resave it as a “frozen” scd file with explicit dependencies: +File { *saveQuarklet { |path, string| /* ... */ } }
• Add a method to thaw a frozen scd, which would require (a) grabbing dependencies, and (b) creating a corresponding sclang-conf, +File { *loadQuarklet { |scdPath, targetFolder| /* ... */ } }

Yes! This is similar the “Project as Quark” idea floated by @josh - see this thread Project as Quark - #5 by smoge

That said, I’m not so sure about the single file / yaml-in-a-comment idea - It might be simpler to for projects to simply be Quarks - that is live in an enclosing folder with a .quark file in it. All the methods you describe could still be implemented. Projects as Quarks can include multiple files, media and binaries that way and be distributable.

@julian

P.S. Let’s not move towards the big silo of VSCode

+1 ( SCNvim user here )