Distributing code - relative path for sclang.conf.yaml

(splitting conversation off from Quark Versioning thread)

@Nathan wrote:

Right now, there is no way to distribute an scd file and class library code, hand them off to someone else, and have them easily run the code in a way that isolates the runtime from whatever else the user has installed. It’s a bunch of little things that add up — problems with relative path support in in sclang_conf.yaml, the IDE’s interface for language config being pretty tucked away and inconvenient, etc. — but I am optimistic that they could be fixed fairly quickly to produce an “isolated run” feature with a nice one-click IDE interface. I’m not able to assist with this but if I were strategizing ways to improve SC’s packaging situation, I would make something like this a top priority.

It seems that having sclang.conf.yaml accept relative paths is a first step - @miguel-negrao was working on this many years ago!!


looking at Miguels commits 85f5f09a1e499012555d0b71d173e52cc0a67096:

sclang and class lib: implements projects

removes sclang -a cmd line option and adds 'excludeDefaultPaths' and 'project' boolean keys to sclang config file.

When 'project:true':
 - Relative paths in the config file are resolved relative to the directory containing the config file.
 - Quarks download to the directory containing the config file.
 - if a file named 'startup.scd' file is present in the same directory as the project file it is run at startup.
When 'excludeDefaultPaths:true'
 - user and system standard directories are not searched for class library files.
 - default startup file is not run.

Paths in the lang config file containing "%ResourceDirectory%", %SystemExtensionDirectory%" or "%UserExtensionDirectory%" get that substring substituted with the equivalent directory. 

I wonder if this code will still build/work… anyone inspired to test? (@nathan)

1 Like

hmm it looks like this PR (awaiting review) might do the trick lang: pass multiple sclang configurations by mraethel · Pull Request #6068 · supercollider/supercollider · GitHub @nathan

Thank you for keeping this alive. I want to stress again that a lot of SC’s biggest long-term problems are due to its lack of modularity, and this would be an important and long overdue step towards that. Unfortunately I’m not actively involved in SC development anymore and I don’t have the bandwidth or motivation to offer direct help.

1 Like

I just built and started testing this on Mac … relative paths working so far! Thanks @mraethel. The multiple conf files is actually pretty neat too at first blush… now if plugins could be handled the same way…


Hey @semiquaver, I’m glad you’re enjoying the features and good to know that it works on Mac! I’ll see if I can do anything about plugins.