Gregor Richards wrote:
> Responses inline. Beware extreme sarcasm.
> 

Don't mind sarcasm as long as your arguments are clear.

> 
>> If you want to use the software's source code, then you should be able to "install" it just by unpacking an archive file, and "unistall" it by deleting said archive/folder. As for dependencies, see bellow:
> 
> God I hate this logic. I've seen it so many times, and it doesn't get any less sensible.
> 
> 1) Have fun doing that with tioport. Awesome for every SWT app to take ten minutes to compile because we're living in the pre-library stone ages.
> 2) Have fun doing that with derelict components. SDL-somefeature and SDL magically merge into one library, and without going and looking up which files are which, you can only uninstall the whole blob.

Who said anything about compiling dependencies? That wasn't my intention, I did mention below that dependencies where in the form of "(headers + binary libraries)".

> 3) Have fun doing that with twenty dependencies. Lesse, this one is in a 'src' directory, this one is over in this corner but oh that actually needs to be installed from this directory, not that one, this one is -- ahh, fuck it, I just won't use any dependencies, I'll write the entire thing without using anything. OR, if those libraries used DSSS, I could either `dsss net deps` or build and install them in a CONSISTENT WAY. Consistency? Yes. Consistency. It's impossible to make tool builds and installs consistent with scripts or the "copy-and-paste to install" mindset.
> 

A project with *twenty* dependencies? Well, yes, in that case it's very likely DSSS would be quite useful, as I mentioned in my previous post.

> Yes, in some limited cases this works. But it's hardly a generic solution - the generic solution should work for both simple and complex libraries, for both few and many dependencies. Boy, I wish somebody would write a tool like that! Oh yeah, somebody did - DSSS.
> 
> 

Yes this is not a generic solution, and it isn't preferable for all cases. My contention is just on how often it is preferable or not. I would say it is more than just "in some limited cases".


> 
>> If it's to mess around with the source, I am of the opinion that a given project distribution should have all of it's dependencies in the distribution as well (headers + binary libraries).
> 
> I'm inclined to respond with an insult. But I won't, because that's mean and a lot of D developers seem to be trapped in this ridiculous mindset. While I know you're never going to change your stance, I'm hoping that other readers will go "Oh, that makes sense" and not disown my methods because I'm a jerk.
> 

Don't be so sure about my stance. I'm trying to understand more scenarios where DSSS would be clearly preferable.

> Have fun maintaining ten branches because you're unwilling to handle dependencies properly. Oh, <X> fixed some file foo.d so that it works on Mac OS X now, I should retry <Y>! ARGH! Now I have to delete the version in the maintainer's archive, copy in the --- damn it, which derelict libraries were in there? Boy, I'm glad he just copies and pastes dependencies, makes my life a beautiful living hell.
> 

Ten branches? You mean one branch for each dependency? Or you mean ten branches of your own project? What is <X> and what is <Y>? I don't understand that situation.

> 
>> For example my last C++ project had SDL, DevIL, GLUT, GLEW and some other deps all bundled in.
> 
> Wow, that's disgusting and unmaintainable. Have fun following the changelogs for all of those and re-duplicating.
> 
> 

Why is it disgusting and unmaintable? Where would I re-duplicate? What's the trouble with following changelogs?

>> It's just simpler that way.
> 
> Oh yeah, and also disgusting and unmaintainable. But yeah, simple.
> 
> 
>> The only problem I see with this approach is redundant disk space
> 
> Sooo, maintaining what is effectively a zero-modification branch just takes disk space, no developer time or effort. Got it.
> 

What do you mean a zero-modification branch?

> 
>> , which is hardly significant.
>> The only scenerio I'm seeing where DSSS could be useful, is when I have project that *I* am developing (ie, not a third part project),
> 
> So, not useful for the third party who would just like to build against the latest, presumably-least-buggy versions? Got it.
> 
> 

If they wan't to use the latest, presumably-least-buggy versions, then just download the new library binaries and replace the old ones. That's in the case where there are no API changes of course.

>> that has a lot of dependencies, *and* where I would want to update those dependencies often during the course of development. And even then, it might be just as easy to have a shell script that downloaded the latest versions of said dependencies, and unpacked them.
> 
> $ dsss net deps
> $ wc -l stupid_downloader_script.sh
> 103765
> 
> 

A download script with 103765 lines, right... Did you program an AI to download a file?
Right now I'm not imagining a download script more complex than either doing an svn/cvs checkout, or using wget to download an archive, and unpacking it. I'm not saying there wouldn't have to be more complex scripts, I'm saying I'm not imagining anything more complex.
Note that I'm talking about a script *specific* to a given project, made by the project's coders, not a generic script that would determine dependencies for any given project and download them (ie., dsss net in script form).


/* ----------  And now, on the binary installation issue  ---------- */


>>
>> As for the Acquisition component (note, I'm not familiar with Perl's
>> CPAN or Ruby's Gems) :
>> Again, if you just want to use the software, then OS-specific
>> facilities should be used, otherwise it's just reinventing the wheel
>> (is this even an intended use-case?)
>
> In the rare case that they're available, yes. It's primarily for libraries.
>

Rare case that they're available??... What kind of context are you talking about?? Maybe I'm hallucinating, but I find that most software (including libraries) has precompiled binaries for the common platforms (Windows, Linux, MacOS).

>> As for the Installation component, well in either two cases:
>> If you just want to use the software (the binaries, not the source
>> code), then OS facilities should be used to install/uninstall the
>> software, not something as specific as DSSS.
>
> In the rare case that that's easy and generic. That rare case being
> true, oh, 0% of the time.
>
> There really is not an OS facility for installation that isn't a PITA.
> You notice that Makefiles just install with 'install', which makes
> non-uninstallable installations. Weeh. DSSS may maintain the manifest
> itself, but at least it /maintains the manifest/.
>


"In the rare case that that's easy and generic." ? Again, what world do you live in?
Ever heard of an OS called Windows? Altough it sucks in a lot of things, it's software installation/uninstallation facility is not one of them. It's quite nice in fact. <sarcasm> There are also rumoreds sightings of mythical beasts such as "Gentoo" and "Ubuntu" which have proper OS installation facilities. They say they even allow uninstallation of software *gasp*. But like most legends, it's likely to fantasious to be true.... </sarcasm>.

Ok, seriously now. Make install?!? C'mon! Make install is not a facility for installation. Make install is not a proper facility for anything. Make install is an hack for OSes without proper install facilities, used by ugly and "hacky" software distributions who think that spreading seven pieces of the software across different locations in one's computer is a good thing.
Yes, this might go against traditional UNIX wisdom, but, as you can see, there are many things in this traditional "wisdom" I don't like, particularly with regards to file system structure.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Christopher Wright wrote:

> Okay, so you're volunteering to maintain the Debian packages for dmd and flectioned? :P

I already created Debian packages for dmd, dmd2 and dsss...

http://movax.mpi.int.pl/d.php