Adam D. Ruppe Wrote:

> Jesse Phillips wrote:
> > You can have the author release packaged libraries for developers
> > to use and the author should do this. So this begs the question of
> > what is the repository for?
> 
> It's so you have a variety of libraries available at once with
> minimal hassle when you are originally writing something.
> 
> I really don't care about those libraries' implementation details.
> I just want it so when I type "import something.lib;" in my
> program it actually works. If something.lib's author wants to
> use other.thing, great, I just don't want to think about it
> anymore than I think about his private classes or functions.

Perfect, so what you want is a is a repository of pre-built packages which have 
all the bells and whistles you need.

> > Why is the tool going out to different URLs and downloading files
> > when you are supposed to use the pre-built lib?
> 
> The second level of downloads is an implementation detail,
> aiming to provide the illusion of a pre-built lib when the
> author didn't actually provide one.

And this is where things stop "just working." You are providing an illusion 
that isn't their. And it is one that is very fragile. You can of course ignore 
the issues and say the software must be maintained to support newer versions of 
the libraries if the feature is to work.

I don't have an answer as to whether this is acceptable. The only way to find 
out is if a successful build tool takes this approach.

> The first level of downloads (the things you actually import in
> your own program) are there for your own convenience. It's
> supposed to make this huge ecosystem of third party libraries
> available with the same kind of ease you get with Phobos. You
> just write "import std.coolness;" and it works. No downloading
> anything, no adding things to the command line.

Right, and since the files are going to be downloaded you have to decide what 
you want to do with them. Pollute the programmers project with all the 
third-party libraries he imported? Save them to a location on the import path?

Both of these are reasonable, but both have drawbacks. It is more common to 
place third-party libraries into a reusable location.
 
> I want third party modules to be equally available. But, just
> like you don't care if Phobos uses zlib 1.3.x internally or
> whatever, you shouldn't care if third party modules do either.
> Phobos comes with "batteries included"; so should everything else.

Yes this is generally how Windows software is developed. Linux on the other 
hand has had a long history of making libraries available to all those who want 
it. Of course it is usually only something to worry about for much larger 
libraries, at which point we have package managers from our OS (well some of us 
do).

> > Having a standard way for which things are built, having easy
> > access to all relevant libraries, and knowing you can find most
> > of what you need in one place. Those are the reasons.
> 
> We agree here. The difference is I'm only interested in the top
> most layer - the modules I import myself. I couldn't care less
> about what those other modules import. In my mind, they are
> just like private functions - not my problem.

Right, unless you are making the software that is trying to hide those details 
from you.

I think there is a fine line between the person using the libraries and the 
person that is adding libraries for other people. We want the barrier to entry 
of both to be as minimal as possible. So the question I want to put forth is 
what is required to be done for that library writer to commit his work for use 
by this magical tool?

Should it be compilable without any command line flags? Should it contain all 
relevant code so their aren't external dependencies? Does it need to be 
packaged in a tar ball? Can it reside in a source repository? Does it need to 
be specified as an application or library?

Creating such a system around your simple needs just means it won't be used 
when things become less simple. Creating a complex system means it won't be 
used if it is too hard to use or it doesn't work.

DSSS seemed to provide a great amount of simplicity and power... the problem is 
that it didn't always work.

Reply via email to