Lester L. Martin II Wrote:

> Jesse Phillips Wrote:
> 
> > On Sun, 28 Jun 2009 03:43:16 +0300, Vladimir Panteleev wrote:
> > 
> > > As recently posted by WB, we should get a Windows installer project going. I think we should first discuss what this installer would contain, which installer framework to use, etc.
> > 
> > So, something like the DInstaller project?
> > 
> > http://dsource.org/projects/dinstaller
> > 
> > Never really got a great amount of interest.
> 
> That was my project. I stopped for a while out of disinterest and I'm working on it a bit, just no commits. I was working on something that would help DSSS net out I think. I haven't finished it yet. If there is any interest please email me, post here, or in the Dinstaller forum part. I'm not just going to let it die, I've just got a bit behind is all.
> 

I was a bit skimpy on the projects plan. It's supposed to end up being a D Installer in D for multiple compiler sets, libraries, and some other stuff and it would use DSSS net to get all these different things once I completed that DSSS Net thing. It would end up being like a "package manager" for D because it could upgrade, downgrade and so much more such as resolve conflicts between libraries ("No, you are not allowed to install that because it is not going to work with what you got, can I recommend you X instead, oh, ok you said no, do you want to install anyway, gosh, you said yes, I'll continue, but don't say I didn't warn ya"). Of course that type of resolving feature wasn't going to make it into first release because that's particularly hard. The upgrade feature would upgrade or fail and not upgrade anything. the downgrade feature is a "just in case" feature. Of course, most of this is conceptual at the moment, though I have a lot of the backend of a DSSS net thing written, I have yet to give it the hooks required to download, and install, and have yet to give it a simple command line interface.

Hello Daniel,

> I actually started sketching out a possible installer a few weeks ago.
> Here's what I came up with:
> 
> First of all, you can't include DMD itself in the installer since the
> license doesn't allow for this.

with Walter's blessing you can. Tango goes this way.

> As for using an installer "tool", I don't think that's really
> applicable for something like this.  I say write it in D because
> otherwise we'll have people saying that D sucks because we don't use
> it.

Um, I've got to say I think you are wrong on this. Installer tools will cut the effort to produce this by like 90%. I'd rather see that time spent on just about anything rather than using D just so we can say we do.

For the initial version, I'd be happy if it downloaded the zip file, unzipped it, and set the path.

Vladimir Panteleev wrote:
<snip>
> In my opinion, the Windows installer's goal is somewhat different than a Linux installer. I've heard many people say that they'd love a simple installer that installs them everything including a build tool, IDE, debugger, etc., so perhaps it should allow installing more than just the barebones DMD.

Perhaps?  Definitely, if you're going to bother with an installer at all.  At least, I can't see any point in having an installer for barebones DMD.

> However, we don't want to include things that many people won't use either. Therefore, I was thinking that the installer could download and install components (libraries, text editors/IDEs or plugins for them, build tools) from the web if the user ticks some corresponding checkboxes.

How is the set of libraries that your installer can install going to be maintained?  Will anyone be able to contribute?

The ideal, however, is to have it so that the user can paste in the URL of any D library and the installer'll install it.  However, until and unless we can standardise how to package a library for download, the user would have to guess whether the installer supports the particular library's way of doing it.

> Further ideas:
> * support Windows' "change" option in Add/Remove Programs to allow removing, reinstalling and updating components
> * when installing an editor, associate .d files with it
> * adjust PATH to include DMD and any selected build tools
> * adjust DMD search paths to point to any additional libraries (Tango, DSSS etc.)
<snip>

Why not install all third-party libraries under a common base path?

Stewart.

On Sun, 28 Jun 2009 08:24:59 +0300, Daniel Keep <daniel.keep.lists@gmail.com> wrote:

> As for using an installer "tool", I don't think that's really applicable
> for something like this.  I say write it in D because otherwise we'll
> have people saying that D sucks because we don't use it.  *sigh*

I've thought a bit about this and I agree. There isn't really much complicated stuff going on during the installation of a Windows application - copy files, create uninstaller, add entry to the Add/Remove Programs list... Using a generic install system is very likely to get in our way as soon as we get past the "download and unpack DMD" phase, because our goal isn't exactly typical, and we need to take varying approaches to maintain different packages. Installer creators will get us a user interface consistent with other installers and that registry setting, but customizing the install process will require using plugin DLLs or helper programs (or using severely limited scripting languages), which could get really messy really fast.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On Sun, 28 Jun 2009 08:23:11 +0300, BCS <none@anon.com> wrote:

> libs? maybe. Tools? No! I hate "installeres" that go out and download what they are supposed to install. For one thing it make it really hard to archive your toolchain.

This would imply that you (and other users) would have to download the entire toolchain every time one tool updates.

Also I think it's pretty clear that Walter would rather have the installer download DMD rather than include it.

What's wrong with compressing your entire D folder, including all settings?

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On Sun, 28 Jun 2009 15:44:04 +0300, Lester L. Martin II <lestermartin92@gmail.com> wrote:

> I was a bit skimpy on the projects plan. It's supposed to end up being a D Installer in D for multiple compiler sets, libraries, and some other stuff and it would use DSSS net to get all these different things once I completed that DSSS Net thing. It would end up being like a "package manager" for D because it could upgrade, downgrade and so much more such as resolve conflicts between libraries ("No, you are not allowed to install that because it is not going to work with what you got, can I recommend you X instead, oh, ok you said no, do you want to install anyway, gosh, you said yes, I'll continue, but don't say I didn't warn ya"). Of course that type of resolving feature wasn't going to make it into first release because that's particularly hard. The upgrade feature would upgrade or fail and not upgrade anything. the downgrade feature is a "just in case" feature. Of course, most of this is conceptual at the moment, though I have a lot of the backend of a DSSS net thing written, I have yet to give it the hooks required to download, and install, and have yet to give it a simple command line interface.

Judging by SVN [1] there isn't much to look at at the moment, so I had a look at the XML example [2]. Some questions:

1) Why do you have a list of downloads? Are these supposed to be mirrors? Or does each one represent a version?
2) What's the difference between package dependencies and download dependencies?
3) Why are the package dependencies in human-readable format (and include Internet location) rather than reference another package by name?
4) Same for download dependencies - aren't a package identifier and version sufficient for a dependency declaration?
5) I don't think installation instructions can be described in only shell commands...

Sorry if that was a very rough draft and your actual design isn't challenged by these questions.

[1] http://dsource.org/projects/dinstaller/browser/trunk/D/Dinstaller%20in%20D
[2] http://www.dsource.org/projects/dinstaller/wiki/pdesc

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On Sun, 28 Jun 2009 10:45:06 +0300, Lutger <lutger.blijdestijn@gmail.com> wrote:

> Wouldn't it be sweet to go further and use dsss as that part of the
> installer which handles the libraries or more? There's probably a good bit
> of useful code in there, or even better dsss could be updated as required by
> the installer project. That will leverage dsss user base and revive dsss at
> once. Plus the way dsss works, it makes it easy to extend the list of
> components in the future.

I actually wanted to look at that as I heard DSSS could actually install DMD and Tango, but it looks like DSSS's sources mirror ( http://dsss.brainsware.org/sources ) has been down for a while now :/

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On Sun, 28 Jun 2009 23:38:27 +0300, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> How is the set of libraries that your installer can install going to be maintained?  Will anyone be able to contribute?

Since this is a community project, it's important not to make any component dependent on a single party. I was thinking of something like DSSS's system, where package maintainers can register and maintain installation/uninstallation "recipes" (not unlike GoboLinux).

> The ideal, however, is to have it so that the user can paste in the URL of any D library and the installer'll install it.  However, until and unless we can standardise how to package a library for download, the user would have to guess whether the installer supports the particular library's way of doing it.

We can do this for libraries containing dsss.conf files.

> Why not install all third-party libraries under a common base path?

Some libraries are packaged with documentation, examples, etc. with the actual source in a subdirectory. On my system I resolve this with a "packages" directory (containing library packages with the directory structure intact) and an "import" directory, which contains symlinks to the libraries' source directories. We can't do this since some users still use FAT32.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

Vladimir Panteleev Wrote:

> On Sun, 28 Jun 2009 15:44:04 +0300, Lester L. Martin II <lestermartin92@gmail.com> wrote:
> 
> > I was a bit skimpy on the projects plan. It's supposed to end up being a D Installer in D for multiple compiler sets, libraries, and some other stuff and it would use DSSS net to get all these different things once I completed that DSSS Net thing. It would end up being like a "package manager" for D because it could upgrade, downgrade and so much more such as resolve conflicts between libraries ("No, you are not allowed to install that because it is not going to work with what you got, can I recommend you X instead, oh, ok you said no, do you want to install anyway, gosh, you said yes, I'll continue, but don't say I didn't warn ya"). Of course that type of resolving feature wasn't going to make it into first release because that's particularly hard. The upgrade feature would upgrade or fail and not upgrade anything. the downgrade feature is a "just in case" feature. Of course, most of this is conceptual at the moment, though I have a lot of the backend of a DSSS net thing written, I have yet to give it the hooks required to download, and install, and have yet to give it a simple command line interface.
> 
> Judging by SVN [1] there isn't much to look at at the moment, so I had a look at the XML example [2]. Some questions:
> 
> 1) Why do you have a list of downloads? Are these supposed to be mirrors?
> Or does each one represent a version?
> 2) What's the difference between package dependencies and download
> dependencies?
> 3) Why are the package dependencies in human-readable format (and include
> Internet location) rather than reference another package by name?
> 4) Same for download dependencies - aren't a package identifier and
> version sufficient for a dependency declaration?
> 5) I don't think installation instructions can be described in only shell
> commands...
> 
> Sorry if that was a very rough draft and your actual design isn't challenged by these questions.
> 
> [1] http://dsource.org/projects/dinstaller/browser/trunk/D/Dinstaller%20in%20D [2] http://www.dsource.org/projects/dinstaller/wiki/pdesc
> 
> -- 
> Best regards,
>   Vladimir                          mailto:thecybershadow@gmail.com

The naming of the project is probably incorrect (since I didn't really worry about it compared to the code), a more complete one is (here http://fsdev.net/repositories/browse/dsss/trunk/backend ) but I haven't merged some of my changes and besides that, I think those changes were lost in my last windows crash (since I was on windows then if I'm correct). However, it's a pretty good starting point. Some of it may need to be updated to latest tango though. At the moment it's a framework pretty much where the application has 3 layers.. the framework, which is protocol independant, the protocol dependant stuff (ftp/http/SOMEODDCREATION) that is a basic set of hooks that comply to a certain function definition and when initing the backend, hook itself into it to get the stuff over the protocol, and then their is the command line level which controls managing all this.... http://fsdev.net/repositories/browse/dsss/trunk/backend It's got the backend pretty much finished if I remember correctly and I had started works on the midend hooks for http and ftp, and then lost that work. It shouldn't be super hard if I remember correctly and it should also all compile (if I remember correctly).