www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why isn't DSSS ('s net portion) more widely used?

reply Robert Fraser <fraserofthenight gmail.com> writes:
DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?
Jun 03 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

How many times have I asked myself this question X-D The unfortunate truth is that most of the tools installable via DSSS aren't even DSSS-maintained. I made the dsss.conf files for them and maintain said dsss.conf files as patches. Basically, it's a chicken-and-egg problem. Because D grew up to where it is with no standard system for installation of libraries, trying to force people to use one now is a bit difficult. I guess all I can say is: If you have some specific library you'd like added to `dsss net`, write the dsss.conf file yourself, and I can add it as a patch. It's a gross, temporary solution, but at least it would allow dependent libraries to be fully DSSS'd. If somebody wants to start a DSSS advocacy group ... ^^ - Gregor Richards
Jun 03 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Gregor Richards wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

How many times have I asked myself this question X-D The unfortunate truth is that most of the tools installable via DSSS aren't even DSSS-maintained. I made the dsss.conf files for them and maintain said dsss.conf files as patches. Basically, it's a chicken-and-egg problem. Because D grew up to where it is with no standard system for installation of libraries, trying to force people to use one now is a bit difficult. I guess all I can say is: If you have some specific library you'd like added to `dsss net`, write the dsss.conf file yourself, and I can add it as a patch. It's a gross, temporary solution, but at least it would allow dependent libraries to be fully DSSS'd. If somebody wants to start a DSSS advocacy group ... ^^ - Gregor Richards

I think it just takes time. I've only started tinkering around with DSSS recently and figuring out how to write DSSS.conf files. (The new developer-oriented docs are very helpful by the way). People who started developing their projects a long while ago already have solutions worked out for compiling their code, and for the most part, nobody is interested in rewriting a build system that works unless they really really have to. But I think it's likely newer projects (and newer D developers) will adopt dsss from the start. ... As long as someone remembers to ask every month or so why dsss/rebuild aren't more popular than they are. :-) --bb
Jun 03 2007
prev sibling next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Sun, 03 Jun 2007 16:30:03 -0700, Gregor Richards wrote:

 Robert Fraser wrote:
 DSSS seems like a great tool... ANy ideas on why it's not more widely used?

How many times have I asked myself this question X-D

Remind me again ... what's DSSS? <G> -- Derek (skype: derek.j.parnell) Melbourne, Australia "Author of Bud :P" 4/06/2007 2:18:19 PM
Jun 03 2007
prev sibling next sibling parent janderson <askme me.com> writes:
Gregor Richards wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

How many times have I asked myself this question X-D The unfortunate truth is that most of the tools installable via DSSS aren't even DSSS-maintained. I made the dsss.conf files for them and maintain said dsss.conf files as patches. Basically, it's a chicken-and-egg problem. Because D grew up to where it is with no standard system for installation of libraries, trying to force people to use one now is a bit difficult. I guess all I can say is: If you have some specific library you'd like added to `dsss net`, write the dsss.conf file yourself, and I can add it as a patch. It's a gross, temporary solution, but at least it would allow dependent libraries to be fully DSSS'd. If somebody wants to start a DSSS advocacy group ... ^^ - Gregor Richards

I think DSSS needs to come setup with any D specific IDEs. Its the best way for it to succeeded. -Joel
Jun 03 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Gregor Richards wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

How many times have I asked myself this question X-D The unfortunate truth is that most of the tools installable via DSSS aren't even DSSS-maintained. I made the dsss.conf files for them and maintain said dsss.conf files as patches. Basically, it's a chicken-and-egg problem. Because D grew up to where it is with no standard system for installation of libraries, trying to force people to use one now is a bit difficult. I guess all I can say is: If you have some specific library you'd like added to `dsss net`, write the dsss.conf file yourself, and I can add it as a patch. It's a gross, temporary solution, but at least it would allow dependent libraries to be fully DSSS'd. If somebody wants to start a DSSS advocacy group ... ^^ - Gregor Richards

All I can offer are my personal experiences with trying to DSSS-ify a few of my projects: I'm still finding it hard to develop reasonably complex DSSS scripts only because there's only one possible mode of testing them: net install. There's no option to execute dsss.conf from the filesystem (via "-file <filename>" or somesuch), so I can't test my dsss.conf file out locally before exposing it to the world (unless I'm mistaken). IMO, that's a big problem. Another thing that's hurting adoption is that DSSS is still left-of-center in the D software landscape. This is that chicken-and-egg problem you cite. This tool won't become the core of anyone's toolkit until everything they could possibly want is supported by it. Other than that, the documentation has come along by leaps and bounds since you started this, Gregor. At first this was a real sticking point, but I'm just now starting to get my head around things. -- - EricAnderton at yahoo
Jun 04 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Pragma wrote:

 I'm still finding it hard to develop reasonably complex DSSS scripts only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

Why can't you use "dsss build" and "dsss install" ? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 04 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Lars Ivar Igesund wrote:
 Pragma wrote:
 
 I'm still finding it hard to develop reasonably complex DSSS scripts only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

Why can't you use "dsss build" and "dsss install" ?

Hrm... maybe I missed an update somewhere along the way. Does it still look only in the current path, or can you specify a path for the dsss.conf file via those two methods? -- - EricAnderton at yahoo
Jun 04 2007
parent reply Gregor Richards <Richards codu.org> writes:
Pragma wrote:
 Lars Ivar Igesund wrote:
 Pragma wrote:

 I'm still finding it hard to develop reasonably complex DSSS scripts 
 only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

Why can't you use "dsss build" and "dsss install" ?

Hrm... maybe I missed an update somewhere along the way. Does it still look only in the current path, or can you specify a path for the dsss.conf file via those two methods?

Yes, it still only looks in the current path. I haven't added your -file option for two reasons: 1) I have no idea why it's supposed to be useful. 2) Nobody else has asked for it. No wait, three reasons: 3) It becomes very ambiguous if you have a subdirectory with its own dsss.conf file: Then you have to answer the question "Should it look at that dsss.conf file, or one relative to the -file provided one?" And whichever way I answer that, 50% of the people who use this feature will think my answer is wrong. Hell, I'll think my own answer is wrong. No! Four reasons: 4) Having the dsss.conf file next to the source just makes sense. While /allowing/ it to be elsewhere is hardly /forcing/ it to be elsewhere, it does encourage confusion. I'd hate to see people go "well, I'm not sure how to integrate my Windows-only dsss.conf and my GNU/Linux-only dsss.conf (using version() blocks is soooooooooo confusing), so I'll just require you to run dsss build -file dsssConfDir/windows/dsss.conf" And, I completely fail to understand how "have to modify the dsss.conf file in place" leads to "can't test it before exposing it to the world." - Gregor Richards
Jun 04 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Gregor Richards wrote:
 Pragma wrote:
 Lars Ivar Igesund wrote:
 Pragma wrote:

 I'm still finding it hard to develop reasonably complex DSSS scripts 
 only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before 
 exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

Why can't you use "dsss build" and "dsss install" ?

Hrm... maybe I missed an update somewhere along the way. Does it still look only in the current path, or can you specify a path for the dsss.conf file via those two methods?

Yes, it still only looks in the current path. I haven't added your -file option for two reasons: 1) I have no idea why it's supposed to be useful. 2) Nobody else has asked for it. No wait, three reasons: 3) It becomes very ambiguous if you have a subdirectory with its own dsss.conf file: Then you have to answer the question "Should it look at that dsss.conf file, or one relative to the -file provided one?" And whichever way I answer that, 50% of the people who use this feature will think my answer is wrong. Hell, I'll think my own answer is wrong. No! Four reasons: 4) Having the dsss.conf file next to the source just makes sense. While /allowing/ it to be elsewhere is hardly /forcing/ it to be elsewhere, it does encourage confusion. I'd hate to see people go "well, I'm not sure how to integrate my Windows-only dsss.conf and my GNU/Linux-only dsss.conf (using version() blocks is soooooooooo confusing), so I'll just require you to run dsss build -file dsssConfDir/windows/dsss.conf"

Good point. Let me ask you this then: is it possible to pass -version through DSSS to the .conf file? I'd be more than happy to maintain things from a single root .dsss file if I can provide different install options in some fashion. Barring that, what is the recommended way to set up sub-projects that share the same root; that's really all that I'm after. Take DDL for instance: there's the SDK (everything), and the pre-built utilities package. The former includes both, where the latter should be stand-alone. Currently, DSSS will only let me support the "everything" option. There's also projects like Enki that have a similar split, as it's a binary bundled with a runtime library for use with generated code. So having the binary's sourcecode *optionally* installed would be a plus, as to reduce confusion. Otherwise, your best option is to install using --prefix, which would dump the runtime library outside the main library location.
 
 And, I completely fail to understand how "have to modify the dsss.conf 
 file in place" leads to "can't test it before exposing it to the world."
 
  - Gregor Richards

No worries Gregor. :) Obviously, I'm not up to speed with DSSS yet, and have yet to completely grok how things are supposed to work. Frankly, I'm glad to be mistaken - that means I'm the only one stuck ATM, which is a good thing for DSSS. -- - EricAnderton at yahoo
Jun 04 2007
prev sibling next sibling parent reply torhu <fake address.dude> writes:
Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. Any ideas on why
it's not more widely used?

For us Windows users, tools like these are a bit foreign. Probably in part because they are command line based, and windows is a bit limited in that department. But I also like to know exactly what I'm downloading, where it's installed etc. Any kind of automated downloading or installation makes that harder. But it's probably a lot easier once you've gotten used to the tool, be it DSSS or whatever. I just don't see it as worth the brain power right now. Maybe I never will. On linux, where the command line is the natural command center, I might have used dsss all the time, who knows. Just having all D related downloads under D:\zips\programming\D\ on my HD is great, because I can just browse that folder if I can't remember the name of a tool or library I know I used a year ago. It's all very basic and human-friendly. Taking the time to figure out how to use a new debugger seems a better investment of time, I already know how to download files and how to build D apps without much trouble. The only library I work on is DAllegro. It's built by bud (considering switching to just batch files) on windows and gnu make on linux and OS X. Maybe I'll make it retrievable through dsss net, but it seems wrong to require a language-specific build tool for something that's so simple to build. But the download part could be a way to get more linux people to try it out. Of course, having to still download the required C library to link with might defeat the purpose. But maybe DSSS can do that to? I don't mean to bash on dsss, I'm just explaining why I'm not using it myself. Except for building Tioport SWT and tangobos, that is. I wish people would explain to me why they don't use DAllegro, but I'm guessing the answer is "SDL for teh win". So be it. Maybe if DSSS' net feature was hooked up to dsource.org somehow? It could download the autogenerated zips of specific revisions of the projects. For all I know, this is already possible.
Jun 04 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
torhu wrote:
 Just having all D related downloads under D:\zips\programming\D\ on my 
 HD is great, because I can just browse that folder if I can't remember 
 the name of a tool or library I know I used a year ago.  It's all very 
 basic and human-friendly.  Taking the time to figure out how to use a 
 new debugger seems a better investment of time, I already know how to 
 download files and how to build D apps without much trouble.

I have not started using DSSS for a while for the same reasons, I was getting along just fine with build. But it's a really nice tool. Some more reasons to use it: - very easy to setup, everything is standard and transparent - automatic dependencies: this is just awesome - candydoc build without hassles - simple for simple projects, but flexible if you need more
 I don't mean to bash on dsss, I'm just explaining why I'm not using it 
 myself.  Except for building Tioport SWT and tangobos, that is.  I wish 
 people would explain to me why they don't use DAllegro, but I'm guessing 
 the answer is "SDL for teh win".  So be it.

SDL for teh win, sorry :)
Jun 04 2007
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

Looking at the docs for 0.65 (README.overview), I see it says that it's based on bud. Is that correct? Are bud and rebuild the same thing, or did the project switch over to using bud instead of rebuild?
Jun 04 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 04 Jun 2007 22:08:49 -0400, Jason House wrote:

 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

Looking at the docs for 0.65 (README.overview), I see it says that it's based on bud. Is that correct? Are bud and rebuild the same thing, or did the project switch over to using bud instead of rebuild?

As far as I know, Gregor took some of the concepts in Bud and wrote Rebuild from the DigitalMars C++ source code of the D-frontend. They are not the same product even though they overlap with some of their functionality. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 5/06/2007 1:20:41 PM
Jun 04 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Jason House wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

Looking at the docs for 0.65 (README.overview), I see it says that it's based on bud. Is that correct? Are bud and rebuild the same thing, or did the project switch over to using bud instead of rebuild?

Outdated documentation bug. Thanks for pointing that out. It does indeed use rebuild. - Gregor Richards
Jun 04 2007