I imagine that there would be a "site" where users would register their modules, and that they would have an account that all of their modules were available under. However, that's really a different sort of thing, and one that wouldn't necessarily require lots of effort. I've been doing something similar with RMS for years. Admittedly, there's not a lot of activity there, but the acutal administrative overhead is pretty low.
I see the repository as an information and distribution for code that is developed according to the published module/build APIs. I think it represents a good balance of freedom for the users and quality for the pike community as a whole.
Bill
On Thu, 16 Oct 2003, Johan Sundstr�m, Lysator @ Pike developers forum wrote:
I'd say you are right on target. Some people will definitely prefer other means of version management, and doing it this way gets rid of all the central maintenance work of accounts and similar too.
/ Johan Sundstr�m, Lysator
Previous text:
2003-10-16 20:22: Subject: Re: module repository ramblings
In CPAN you can browse the available modules by author. Once you install them, they still get installed in the same place. On the download site, it's basically the equivalaent of a bunch of symlinks.
As far as CVS goes, you're not going to have a great big tree, because that's not how the modules get built. They [the modules] also probably wouldn't be housed in a single CVS repository anyhow. Each module developer gets to develop the module how they want. The repository is just for making modules available (search, download and build).
Am I heading in the wrong direction with this line of thinking?
Bill
On Thu, 16 Oct 2003, Martin Baehr wrote:
this got me wondering it it is possible (and does it make sense) to seperate the class hierarchy from the directory structure?
looking at CPAN you can access the modules not only by class but also by author (and maybe other criteria)
of course for the webinterface this can be solved by links, but from a cvs perspective having a directory by author may make more sense.
combining these should be no harder than simply having multiple directories with classes in them, so that the pike user only sees one class tree. it only gets interresting if the same class is in multiple trees.
considering the issue of conflicting implementations of the same class, these would be no problem then, because if both classes are installed, one will be chosen automaticly, or i remove one and the other will be used without needing to change the code.
this also allows selecting the classes by author and license. (it may not be wise to mix stuff with different licenses)
on the other hand having a shared tree promotes shared authorship, but this is just the situation we have now, because with shared authorship we need to agree on the license, which brings all the trouble that is keeping some people from contributing now.
greetings, martin.
/ Brevb�raren