Hi All,

One of the things that came up at the Csound Conference is namespaces
and build tools. This also touches on code organization practices.
I'd like to discuss that here to get everyone's input as I think it is
important we figure out how to move forward for this.

For namespaces, I started an issue on the tracker here:

https://github.com/csound/csound/issues/532

The purpose of namespaces is to allow code to be organized into
modules or packages. This allows for one to say, define an opcode
called "my_opcode" in two different namespaces. From here, it allows
users to import both definitions and use them both, even though they
have the same opcode name.  The pseudo-code in issue #532 is just
there to get the idea going, and I'd ask others to come up with other
proposals.

Namespaces has two different aspects I think we need to consider.
First, how to define code within namespaces.  The other, how to import
code from other namespaces and use that code.  This also has an impact
on code organization: how should code be organized into files, and how
will those files be discovered and included into a project.
There's a number of different approaches between Java, Python, C++,
ML, Haskell, etc.  It'd be good to get a discussion going regarding
what we'd like.

For a build tool (let's call it CBT, or Csound Build Tool, for now),
the idea is that this would allow one to define dependencies between a
project and libraries of Csound code.  With CBT, the idea I had was to
allow defining a github repo, and optionally a tag, as a dependency.
(This is inspired by Vundle, a package manager for Vim.) What this
would allow then is User A to define their library code in github repo
user-a/my-library.  A person could then import that code just by
defining the dependency, such as:

[user-a/my-library v1.1]

then running "cbt deps" would automatically download that repository's
contents in a way that works with the project's import statements.

I think CBT could offer commands such as:

* make - render's a project to disk
* realtime - run a project for realtime
* deps - download dependencies
* export - generates a zip archive
* ubercsd - embeds all includes and dependencies into a single CSD

The last command I think could be important. The idea there is to
allow easy working with projects on the desktop, but then packing into
an ubercsd to allow easy embedding into non-desktop projects (i.e.
iOS, Android, Web).

I think namespaces, imports, and code organization is a
higher-priority idea to develop first, while CBT could come
afterwards.

Any feedback very welcome!

steven

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here