Re: Euphoria Prerequiste Manager
On Thu, 25 Sep 2003 15:42:09 +0000, Jonas Temple <jtemple at yhti.net>
wrote:
<snip>
> I don't include Win32Lib
ditto.
>What I'm proposing=20
>is a community created/supported system called "Euphoria Prerequisite=20
>Manager".
Sounds like an interesting project.
<snip>
>* I have a directory on my PC that contains all the files for my nifty=20
>new software (except the prerequisites).
I could craft a package manager which lets you develop on your
existing setup, then can be run against the main source & generates a
list of include files & the directories they live in. Other files
(databases, bitmaps etc) could be listed from the initial directory
with checkboxes, and the yes/no's saved between releases.
>A package definition will be an .edb file containing all of the=20
>information, including all files.
I think there needs to be a strong distinction between an application
package definition, which should only be distributed with the
application itself, and a library package definition, which records
available versions etc and is updated infrequently (eg monthly).
See my plan, below
>* I go to the RDS web site, go to the submission form and point to the=20
>.edb package definition file. RDS validates the data and adds to the=20
>master package definition file.
I think you need only do that for libraries, and although we might
hope Rob will volunteer, we shouldn't assume he will. There's a url
issue in my master plan, see below.
>* Interested user now wants to try my cell phone package. He goes to=20
>the recent contributions page and selects my package. What he/she gets=20
>is a file that contains my package and all prerequisites as I have=20
>defined.
=46irst sticky point. Is that zipped? See my plan below.
>* Interested user now runs a program in Euphoria/bin that extracts the=20
>packages. For each package, the program asks the user where the=20
>directory that I created should be extraced on their PC (I would choose=20
>C:\EuTools since that's where all of my user contributed files are). =20
>The program would also ask where the include files should be placed and=20
>defaults the location to 1) first directory in EUINC 2) include=20
>directory in the EUDIR variable.
>* Interested user can now run my program and he/she does not have to=20
>find all the prerequisites manually.
>
>Okay, don't run off scared! I know it sounds like a lot. Fact is, this=
=20
>will REQUIRE the cooperation of the community AND RDS. What we will=20
>gain is easier distribution/management of user-contributed files.=20
>I think this will also require us to create our own=20
>compression/decompression routine for the packages. We can't assume=20
>that everyone has WinZip or equivalent.
Euman has posted a little wrapper for lz32.dll on his h20 site, and
claims to have tested it against the standard windows compress
utility. That may be the best starting point. I'll assume we go with
this and call it an lz file from now on.
>
OK here's an outline plan:
<obviously open to severe criticism: first draft 'n all>
1) The install manager.
We write a smallish standalone executable (say 400K maximum, which is
between 40 and 80 seconds download on a 56K modem). It won't be zipped
(I think that only saves 5-10% anyway on an executable). This program
needs a url (which is almost certainly a file of all the other urls,
the first of which is the requirements list).
This is the main trick I haven't worked out (that url), maybe Rob
could serve a patched copy of a standard program from the rds server,
that is, if we do most of the groundwork...?
This program can check to see if Euphoria is installed (if needed) and
perhaps perform a few sanity checks on it. It can scan round the
EUDIR/include and EUINC paths and see what it can check off the list.
It can then prompt for an install directory and begin the process of
unpacking the needed files there.
=46inally, it can invoke the main program when everything is done.
2) The library package info.
This list is needed most at application package time.
One great feature would be that the installer can compare the
historical requirements/versions against the current list, and pop-up
warnings if any files are no longer available, or have been replaced
by more recent versions (which implies the application should have
been tested and re-packaged against them).
This begs the question of how this is built & how it is maintained.
Obviously, a library writer must be able to update details, as can an
application developer needing to use a five year old include, as can a
user reporting that an include file is no longer available online.
Sure, I could hack Peter Blue's web server and write a web front-end
to semi-automate the process, but I doubt anyone would seriously want
such served on this particular pile of junk. Other choices?
Remember (in my scheme of things) this is simply a repository for info
which would otherwise get forgotten, not a bleeding-edge style thing.
If you need, this week, to use a lib released last week, that's kind
of a different matter, and you best deal with that yourself.
3) Decisions, decisions.
Where do we put stuff when we install it?
I think we have four clear choices:
a) bung it all it EUDIR/include (yuk).
b) create new directories under the EUINC variable and hope it don't
get too long (can't remember how many characters you're allowed)
c) store them in EUDIR/managed/library/version, but the install
manager simply dumps a copy of every required file in the local
directory.
d) as c), but not files available in the EUDIR/include or EUINC
directories. However that's the same as dll hell.
I vote for c), since, really, they tend to be tiny.
Maybe an option for d), with a program to re-check stuff.
4)The package builder.
(There are several other examples of this kind of processing in the
archives), I could easily amend my EUBNF program to parse a complete
project and during the process save a list of referenced files. It's a
bit slow (IIRC 80 secs for win32lib, 3 mins for Judith's IDE; though
you can possibly ignore that if you are not using a 5 year old heap of
junk like I am). However, I may have more success with literal files,
not that it will ever interpret non-literal loads.
The same list format would be used for application package definitions
and library package definitions.
I might have missed a whole step or two there, but I've run out of
steam. Unless I'm seriously missing something, I think I've got most
of this already sorted in my head, bar that initial url. Lots and lots
of details to fill out, of course. Some food for thought, I hope.
Pete
|
Not Categorized, Please Help
|
|
