Csound Csound-dev Csound-tekno Search About

[Csnd] Csound Package Manager Proposal

Date2012-11-04 16:54
FromSteven Yi
Subject[Csnd] Csound Package Manager Proposal
Hi All,

In response to an email earlier about the UDO database and make it easier, I had the thought to replace it with a package system and package manager. I am imagining something like ruby gems, CPAN (perl), Hackage (haskell), etc.  I could imagine this being useful for not just UDO's, but other things as well, such as native opcodes (could be C/C++, could be faust, etc.), resources (imagine sample sets, impulse responses, etc), or just about anything. I could see documentation for any package also being aggregated on the local computer into a docs folder, and examples could be downloaded into that folder.  My thought is that the package manager could download everything into a subfolder of INCDIR so that things like UDO's could be #include'd, or also downloaded into the local directory so that dependencies could be packaged up with the project.

Some things I can think of for requirements:

* Package Manager is not tied to one server; this would allow there to be a public server, mirrors, local servers so that educators can say, create a set of example UDO's and things to use

* Package manager could be used to:
    -update package list from server(s)
    -list packages (available, installed)
    -install package (and dependencies)
    -get detailed info on package
    -check dependencies on other packages
    -remove package

* Packages could have:
   -package recipe (files to install, what to build if necessary)
   -text/binary files
   -dependencies on other packages (by version)
   -versions

The nice thing I can see about this is that it could be useful not only for community resources, but even useful for individual work, where you might share UDO's and other things between projects.  The central repository and mirrors could be considered stable (packages not expected to be deleted once published), while individuals can create their own package repos for experimental work to share with others.  We could have a unstable/stable system as well for packages, with some degree of community verification to move packages up to stable. 

Package systems as a whole are implemented in a lot of different programming languages as well as used to back most linux distributions.  I thinking moving in that direction could be very positive for the Csound community.

Thoughts?

Thanks!
steven

Date2012-11-04 17:05
FromSteven Yi
Subject[Csnd] Re: Csound Package Manager Proposal
One thing that I thought about that could be a problem is name clashes for UDO's and other things.  We may need to create a namespace system in Csound6 to address this, so a proposed Package Manager may require Csound6 to be implemented.


On Sun, Nov 4, 2012 at 4:54 PM, Steven Yi <stevenyi@gmail.com> wrote:
Hi All,

In response to an email earlier about the UDO database and make it easier, I had the thought to replace it with a package system and package manager. I am imagining something like ruby gems, CPAN (perl), Hackage (haskell), etc.  I could imagine this being useful for not just UDO's, but other things as well, such as native opcodes (could be C/C++, could be faust, etc.), resources (imagine sample sets, impulse responses, etc), or just about anything. I could see documentation for any package also being aggregated on the local computer into a docs folder, and examples could be downloaded into that folder.  My thought is that the package manager could download everything into a subfolder of INCDIR so that things like UDO's could be #include'd, or also downloaded into the local directory so that dependencies could be packaged up with the project.

Some things I can think of for requirements:

* Package Manager is not tied to one server; this would allow there to be a public server, mirrors, local servers so that educators can say, create a set of example UDO's and things to use

* Package manager could be used to:
    -update package list from server(s)
    -list packages (available, installed)
    -install package (and dependencies)
    -get detailed info on package
    -check dependencies on other packages
    -remove package

* Packages could have:
   -package recipe (files to install, what to build if necessary)
   -text/binary files
   -dependencies on other packages (by version)
   -versions

The nice thing I can see about this is that it could be useful not only for community resources, but even useful for individual work, where you might share UDO's and other things between projects.  The central repository and mirrors could be considered stable (packages not expected to be deleted once published), while individuals can create their own package repos for experimental work to share with others.  We could have a unstable/stable system as well for packages, with some degree of community verification to move packages up to stable. 

Package systems as a whole are implemented in a lot of different programming languages as well as used to back most linux distributions.  I thinking moving in that direction could be very positive for the Csound community.

Thoughts?

Thanks!
steven


Date2012-11-04 18:22
FromMichael Gogins
SubjectRe: [Csnd] Re: Csound Package Manager Proposal
We discussed this at the 2011 Csound conference, and my impression is that everyone thought it was a good idea. I certainly think it's a good idea. If namespaces can be added without too much trouble they should be, but if namespaces are too much trouble, let's just do it without them, such collisions would not be that common in the real world and someone would just change a name to deal with it.

Best,
Mike


On Sun, Nov 4, 2012 at 12:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
One thing that I thought about that could be a problem is name clashes for UDO's and other things.  We may need to create a namespace system in Csound6 to address this, so a proposed Package Manager may require Csound6 to be implemented.


On Sun, Nov 4, 2012 at 4:54 PM, Steven Yi <stevenyi@gmail.com> wrote:
Hi All,

In response to an email earlier about the UDO database and make it easier, I had the thought to replace it with a package system and package manager. I am imagining something like ruby gems, CPAN (perl), Hackage (haskell), etc.  I could imagine this being useful for not just UDO's, but other things as well, such as native opcodes (could be C/C++, could be faust, etc.), resources (imagine sample sets, impulse responses, etc), or just about anything. I could see documentation for any package also being aggregated on the local computer into a docs folder, and examples could be downloaded into that folder.  My thought is that the package manager could download everything into a subfolder of INCDIR so that things like UDO's could be #include'd, or also downloaded into the local directory so that dependencies could be packaged up with the project.

Some things I can think of for requirements:

* Package Manager is not tied to one server; this would allow there to be a public server, mirrors, local servers so that educators can say, create a set of example UDO's and things to use

* Package manager could be used to:
    -update package list from server(s)
    -list packages (available, installed)
    -install package (and dependencies)
    -get detailed info on package
    -check dependencies on other packages
    -remove package

* Packages could have:
   -package recipe (files to install, what to build if necessary)
   -text/binary files
   -dependencies on other packages (by version)
   -versions

The nice thing I can see about this is that it could be useful not only for community resources, but even useful for individual work, where you might share UDO's and other things between projects.  The central repository and mirrors could be considered stable (packages not expected to be deleted once published), while individuals can create their own package repos for experimental work to share with others.  We could have a unstable/stable system as well for packages, with some degree of community verification to move packages up to stable. 

Package systems as a whole are implemented in a lot of different programming languages as well as used to back most linux distributions.  I thinking moving in that direction could be very positive for the Csound community.

Thoughts?

Thanks!
steven




--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Date2012-11-04 21:15
Fromzappfinger
Subject[Csnd] Re: Csound Package Manager Proposal
Why not also think about a real database where things can be stored and
retrieved by queries, like 'effect UDO', 'Fluid Soundfonts', 'Hammond', etc?

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-Package-Manager-Proposal-tp5717665p5717675.html
Sent from the Csound - General mailing list archive at Nabble.com.

Date2012-11-04 21:26
FromSteven Yi
SubjectRe: [Csnd] Re: Csound Package Manager Proposal

Databases are part of every package management system and include search facilities. The search should be done locally after syncing with the latest package lists.

Steven

On Nov 4, 2012 9:16 PM, "zappfinger" <zappfinger@gmail.com> wrote:
Why not also think about a real database where things can be stored and
retrieved by queries, like 'effect UDO', 'Fluid Soundfonts', 'Hammond', etc?

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-Package-Manager-Proposal-tp5717665p5717675.html
Sent from the Csound - General mailing list archive at Nabble.com.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"


Date2012-11-04 21:34
FromSteven Yi
SubjectRe: [Csnd] Re: Csound Package Manager Proposal

Hi all,

Thanks all for the replies!

I think what I'll do tomorrow is start a bitbucket project just to get something started. My thought is to use python, sqlite, and either XML for the server side to read from or json. I am thinking Python to start as it's a language that a lot us know and we should be able to prototype quickly with it. We can look at other languages later if need be, and if we use sqlite, there are plenty of bindings in other languages for easy transition. Regardless, the discussion on what is required can continue on here and the Wiki space for the project can contain design notes.

A server side will also be necessary, but can be done later and in parallel. For now, flat files can be used for development and testing.

Thanks!
Steven

On Nov 4, 2012 6:22 PM, "Michael Gogins" <michael.gogins@gmail.com> wrote:
We discussed this at the 2011 Csound conference, and my impression is that everyone thought it was a good idea. I certainly think it's a good idea. If namespaces can be added without too much trouble they should be, but if namespaces are too much trouble, let's just do it without them, such collisions would not be that common in the real world and someone would just change a name to deal with it.

Best,
Mike


On Sun, Nov 4, 2012 at 12:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
One thing that I thought about that could be a problem is name clashes for UDO's and other things.  We may need to create a namespace system in Csound6 to address this, so a proposed Package Manager may require Csound6 to be implemented.


On Sun, Nov 4, 2012 at 4:54 PM, Steven Yi <stevenyi@gmail.com> wrote:
Hi All,

In response to an email earlier about the UDO database and make it easier, I had the thought to replace it with a package system and package manager. I am imagining something like ruby gems, CPAN (perl), Hackage (haskell), etc.  I could imagine this being useful for not just UDO's, but other things as well, such as native opcodes (could be C/C++, could be faust, etc.), resources (imagine sample sets, impulse responses, etc), or just about anything. I could see documentation for any package also being aggregated on the local computer into a docs folder, and examples could be downloaded into that folder.  My thought is that the package manager could download everything into a subfolder of INCDIR so that things like UDO's could be #include'd, or also downloaded into the local directory so that dependencies could be packaged up with the project.

Some things I can think of for requirements:

* Package Manager is not tied to one server; this would allow there to be a public server, mirrors, local servers so that educators can say, create a set of example UDO's and things to use

* Package manager could be used to:
    -update package list from server(s)
    -list packages (available, installed)
    -install package (and dependencies)
    -get detailed info on package
    -check dependencies on other packages
    -remove package

* Packages could have:
   -package recipe (files to install, what to build if necessary)
   -text/binary files
   -dependencies on other packages (by version)
   -versions

The nice thing I can see about this is that it could be useful not only for community resources, but even useful for individual work, where you might share UDO's and other things between projects.  The central repository and mirrors could be considered stable (packages not expected to be deleted once published), while individuals can create their own package repos for experimental work to share with others.  We could have a unstable/stable system as well for packages, with some degree of community verification to move packages up to stable. 

Package systems as a whole are implemented in a lot of different programming languages as well as used to back most linux distributions.  I thinking moving in that direction could be very positive for the Csound community.

Thoughts?

Thanks!
steven




--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Date2012-11-05 15:41
FromSteven Yi
SubjectRe: [Csnd] Re: Csound Package Manager Proposal
Hi All,

I've setup a project at:


I'm currently having problems with bitbucket as a whole (unable to push/pull with GIT) and have filed a request with support.  When that's resolved, I'll start working on commits.  All are invited to join!

steven


On Sun, Nov 4, 2012 at 9:34 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi all,

Thanks all for the replies!

I think what I'll do tomorrow is start a bitbucket project just to get something started. My thought is to use python, sqlite, and either XML for the server side to read from or json. I am thinking Python to start as it's a language that a lot us know and we should be able to prototype quickly with it. We can look at other languages later if need be, and if we use sqlite, there are plenty of bindings in other languages for easy transition. Regardless, the discussion on what is required can continue on here and the Wiki space for the project can contain design notes.

A server side will also be necessary, but can be done later and in parallel. For now, flat files can be used for development and testing.

Thanks!
Steven

On Nov 4, 2012 6:22 PM, "Michael Gogins" <michael.gogins@gmail.com> wrote:
We discussed this at the 2011 Csound conference, and my impression is that everyone thought it was a good idea. I certainly think it's a good idea. If namespaces can be added without too much trouble they should be, but if namespaces are too much trouble, let's just do it without them, such collisions would not be that common in the real world and someone would just change a name to deal with it.

Best,
Mike


On Sun, Nov 4, 2012 at 12:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
One thing that I thought about that could be a problem is name clashes for UDO's and other things.  We may need to create a namespace system in Csound6 to address this, so a proposed Package Manager may require Csound6 to be implemented.


On Sun, Nov 4, 2012 at 4:54 PM, Steven Yi <stevenyi@gmail.com> wrote:
Hi All,

In response to an email earlier about the UDO database and make it easier, I had the thought to replace it with a package system and package manager. I am imagining something like ruby gems, CPAN (perl), Hackage (haskell), etc.  I could imagine this being useful for not just UDO's, but other things as well, such as native opcodes (could be C/C++, could be faust, etc.), resources (imagine sample sets, impulse responses, etc), or just about anything. I could see documentation for any package also being aggregated on the local computer into a docs folder, and examples could be downloaded into that folder.  My thought is that the package manager could download everything into a subfolder of INCDIR so that things like UDO's could be #include'd, or also downloaded into the local directory so that dependencies could be packaged up with the project.

Some things I can think of for requirements:

* Package Manager is not tied to one server; this would allow there to be a public server, mirrors, local servers so that educators can say, create a set of example UDO's and things to use

* Package manager could be used to:
    -update package list from server(s)
    -list packages (available, installed)
    -install package (and dependencies)
    -get detailed info on package
    -check dependencies on other packages
    -remove package

* Packages could have:
   -package recipe (files to install, what to build if necessary)
   -text/binary files
   -dependencies on other packages (by version)
   -versions

The nice thing I can see about this is that it could be useful not only for community resources, but even useful for individual work, where you might share UDO's and other things between projects.  The central repository and mirrors could be considered stable (packages not expected to be deleted once published), while individuals can create their own package repos for experimental work to share with others.  We could have a unstable/stable system as well for packages, with some degree of community verification to move packages up to stable. 

Package systems as a whole are implemented in a lot of different programming languages as well as used to back most linux distributions.  I thinking moving in that direction could be very positive for the Csound community.

Thoughts?

Thanks!
steven




--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com