Hyperion Entertainment Message Boards

Hello,

I have pondered for a longer time whether packages that appear on not only OS4Depot but elsewhere should be packaged in a uniform manner - especially applications.

So the questions and issues raised here are not only relevant to Orgin (who I believes is the current maintainer of OS4Depot), but also the Development Team and the wider developer community.

Are there any guidelines that have been laid down anywhere that developers should try and adopt, best practices and such like when it comes to packaging their software for distribution?

If I may elaborate. As some of you may know I am responsible for Jack (http://www.os4depot.net/index.php?funct ... h/jack.lha ). One component of Jack is the App Store. It shows applications that appear on OS4Depot outside the world of the browser. A user can look at information about a package (the readme file) or even download it from within Jack - complete with progress bar. Jack will then extract the archive to the Downloads drawer (if using Push4Dock) or an elected download path.

Now, I'd like to expand this further to something akin to Apple's App-store.

1. I'd like Jack to not only extract the archive, but also detect whether the package has an Installation Script and if so run it automatically.
2. On finishing the installation and quiting the installation script assuming the installation doesn't require a reboot - I'd like Jack to then run the arexx scripts (which are natively available in AmigaOS 4.x) to add the Application to the AmiDock.

In an ideal world this should be straightforward, but every package is set out differently in the archive.

So once again is there a guideline set out by anyone in regard to how a package should be set out in terms to the directory structure?

After looking at various archives I suspect not, I am not saying that submitters should be compelled to adopt a strict directory structure, but it will surely prove beneficial to everyone involved.

Common inconsistencies I've seen in archive file structure:

Problem: Person doesn't include an outer drawer for their application. (My pet hate)
Symptom: When the archive is extracted random files are scattered into the selected destination drawer.
Best Practice: Include an outer drawer in the archive with everything the package contains within.

Problem: There is no installation script.
Symptom: User is free to do whatever, package might also say install X, Y, Z manually.
Best Practice: Include an installation script with a common filename; eg. Install X.

Problem: There is an installation script, but its filename doesn't begin with the word Install.
Best Practice: Include the world Install in the filename.

Problem: There is an installation script, but it requires third-party libraries or datatypes that are freely available.
(Unrelated to the purpose of this thread, but still damn important!)

Best Practice: Now you have two choices, 1) Include the required third party components in the archive if the license allows it or 2) Consider using Wget or similar to do the dirty work for them and download the required resources.
This is of course depends on the nature of the third-party resources... if its just a library simply copy it to libs after performing a version check.

My suggested file archive structure for a program called Example:

Example/
Example/Install Example
Example/Install Example.info
Example/Distribution*
Example/Distribution/Example
Example/Distribution/Example.info
Example/Distrbution/Libs**

* A self-contained drawer with an appropriate title.
** If required a libraries drawer containing freely available libraries that can easily be called upon during an installation script.

Of course the directory structure can differ from application to application, some may choose to remove the Distribution drawer entirely, but it would be ideal if I could detect the Installation Script itself more easily.

---

And then of course there are different Installation Script types.  Some people use batch files contain AmigaDOS commands and call requestfile etc.. to pull it off. Some people use the old Commodore Installer, some of us use Python to do this. And there are these 'things' called Auto-Install?

What approach should Jack take? I'd love for it to purely use Python scripts only - as this is the official AmigaOS protocol right?

Incidentally, how does one actually create an installation script in Python? Does anyone have an example showing how I would create a drawer, copy files/drawers X, Y and Z, check a file version etc...?

I meant to keep this short, but ha so much to discuss.

Look forward to responses.

Rick

As this is Hyperions support forum, I'm not sure this is really relevant here.

At the very least, you are probably better off posting this on a general AmigaOS forum like amigans or amigaworld.

Simon

Thanks, I'll make a post on Amigaworld as well then.

But it is relevant to AmigaOS and is calls into question the issue of standardisation. Also my questions in regard to making a Python installation script are quite appropriate here. Timberwolf use a Python script to perform correct installation right? The Frieden are probably best placed to point in my in the right direction. Is there a detailed account, i.e. relevant documentation on how we should make installation scripts using Python? Codebench uses the Installer application right? Was that written in Python?

Thanks.

Well, the problem with standardisation is that someone has to sit down an design what those standards should be. As you say, the Installation Utility would be a good candidate for that, but it currently lacks public documentation on how to use it from python scripts. Ideally, it should be reagrded as the next successor to the old legacy Installer, but until it is publically documented, this can't happen. The only real person with enough inside knowledge on it is currently very busy with other things, and the documentation for such a tool is rather low priority right now.

And no, CodeBench doesn't use it, as I couldn't really work out how to use it either

Simon

Thanks for your honest and open reply. It will become especially important when the 4.2 release is out there in the wild so I do hope those involved do allocate time to have the proper documentation in place.

Another question, this Arexx script/call that adds an application to the AmiDock. Does it correctly check for duplicates or do I have to perform this integrity check myself? As the AmiDock is built purely on an xml solution it should be simple enough for me to see if there is already an instance in place, but it would be even better if the arexx call actually did this for me. Anyone able to clarify?

I think it is next to impossible to squeeze every application into a common framework. Other systems rarely do that either.

Linux/UNIX has a rigid directory structure, and therefore packaging stuff is simple IF you stay within distro.
MacOS has bundles, most apps appear as a single icon/object that you can drag around as you like.
Windows has "Program Files" and "Program Files (x86)", but even there there is no overall structure.

Now you might say things can be different on AmigaOS, and I agree, but still, it's trying to squeeze things into a framework that doesn't necessarily fit.

@djrikki
This is an interesting but complex topic, which I surely can't do justice to (so I won't try!), although the above replies probably cover the most important points.

I don't think Amiga installers have really progressed since AmigaOS 2.0 days! As you say, there are no real guidelines, beyond using the official (Lisp based) Installer... which many developers (including myself) don't use!

I also agree with pretty much all your suggested guidelines; they make a lot of sense.

BTW, the (AmigaDOS) AutoInstall scripts are the closest we have to a new installation standard, although I think they are only aimed at updating existing installations, since they are intended for use with AmiUpdate.

ChrisH wrote:As you say, there are no real guidelines, beyond using the official (Lisp based) Installer... which many developers (including myself) don't use!

It might be worth considering why that is (finding it too complicated to write scripts for is probably the main one), and then looking at whether the new Python-based installer solves that problem (looking at the available examples I'd suggest it doesn't, although from a user's POV it is a massive improvement)

@chris
I can't speak for anyone else, but I don't use the Lisp-based installer because it's another (and quite strange!) language to learn, and I'd rather use that time for programming. I guess if I make enough things that need an installer, then I might be able to justify learning it...

Installing using Python would not help in this case, since I don't know it either! I guess it would be nice if there was some installer system based upon C. If it was done using an AmigaOS library, then it could be exposed to any programming language you wanted (including interpreted languages with some extra effort). Just a thought anyway.

ChrisH wrote:@chris
I can't speak for anyone else, but I don't use the Lisp-based installer because it's another (and quite strange!) language to learn, and I'd rather use that time for programming.

Fair enough, but it's actually easier than it looks!

Installing using Python would not help in this case, since I don't know it either!

Me neither. I did have a go at learning it when it was first added to OS4, but didn't get anywhere. Installer is way easier.