Allow a global installation folder

[DavinChurch]

I have toolkits that I make use of in many applications. I don't want to have to install duplicates of each of these toolkits in every application directory on my system. In fact, some of my small applications don't even reside in separate directories, and I may have hundreds of them.

This could also be an issue when I have sub-applications that require different sets of packages for support of the different layers. I don't want to have to load all the packages into the top-level application, nor do I want to have to load duplicates of everything throughout the application structure.

What I'd like to be able to do for such a situation is be able to install all the toolkits I use in a global directory (such as C:\Packages). Then I can use LoadDependencies in each application to bring in the tools that I need for that application.

Actually, I can force Tatin to do most of that for me, even though it's not part of the basic design. But where it becomes more of a problem is that when I LoadDependencies I get ALL the packages loaded from the global store, even those I don't want. So to improve this situation, I'd like a way to load only selected packages into a given application. I think this could be accomplished by simply changing or adding to the parameters for LoadDependencies, without any other modifications to Tatin. If this were made optional, then it could be used both in the way I describe here as well as in the way it was originally designed, without compromise.

One possible method for accomplishing this is to allow the package-containing directory name to also include the (full or partial) name of a particular package, to indicate that only that package is to be loaded. Alternatively, the selected package(s) could be optionally added to the end of command line arguments.

This seems to be a relatively simple request that doesn't impact existing functionality but provides more flexibility for users that wish to use Tatin in slightly different ways.

[aplteam]

This goes against the grain of Tatin.

@morten? @gil?

[DavinChurch]

I don't see how this is detrimental to any designed use of Tatin. It's simply an extension to allow the user a choice in how to use it. It doesn't prevent the original method of doing things at all. A reasonable (and non-harmful) choice is good, is it not?

[DavinChurch]

Perhaps if I explained my alternative if I don't have an extra optional parameter in Tatin...

Say I've installed 20 packages (in a common area, which is possible for me to do), but I only need one of them in a simple new workspace I'm starting to build. For the simplest case, I LoadDependencies to load all 20 installed packages and then go through and erase 19 of the namespaces from my workspace along with their direct references. This isn't too horrible if I have to do it only once.

However, if my desired package has one or more dependent packages, then I have to go through and figure out the appropriate dependencies manually and erase only the ones that aren't needed. This is one of the primary jobs of Tatin and I'd have to be doing it completely manually. And if I ever have to rebuild the workspace or reinstall new versions then I have to start over and do the entire procedure again from scratch. And again the next time, etc. And that's just for one simple workspace.

So it seems to me a trivial improvement to allow extra argument(s) on the command line to allow me to just load the packages that I want to use (along with their dependencies). It solves all my problems with the above (and similar) scenarios, offers flexible options to all users, changes nothing to anyone using Tatin as originally designed, changes nothing in the overall scope or design or purpose of Tatin, and requires rather trivial changes to the Tatin codebase. I can't see any disadvantages to allowing this option and it can provide considerable functionality and ease-of-use in certain situations, extending Tatin's usefulness overall.

[aplteam]

@morten: if you do not object I am going to implement this as an experimental feature.

[e9gille]

I think you are asking the wrong Morten. @mkromberg

[e9gille]

I see I managed to post my message in the wrong discussion thread (#57 (comment)).

Is the reason for this to save space?

The current design is based on each folder specifying its requirements, so there are implications in using a single folder for all applications and then dynamically filtering what to be loaded. This may be exactly what is desired here, but I want to be sure we are solving the right problem.

[DavinChurch]

Thank you. I think that simply loading uninstalled packages would work well for my traditional situation. If I need something with external resources then I'll just have to provide an install area in which to store it. Large or disk-based projects can be given their own installation folders as designed.

[DavinChurch]

When you're discussing caching, I can see two possible ways to work ... one is disk caching with a common installation area like I originally requested, and another I think would be handy to consider would be session caching.

For instance (in my case), if I installed all my frequently-used packages into ⎕SE (and perhaps saved them there or set up an auto-install upon starting) instead of saving in a disk directory or loading them in each WS, then I wouldn't need to )SAVE a separate copy in every WS. I could instead just reference the shared ⎕SE namespaces directly from each application as needed. Of course, for anything I would be distributing off my machine I'd be sure to load them directly into the workspace (or install them in the app directory), but I have so many WSes that I just use for myself that I think that ⎕SE caching would be quite beneficial personally while still allowing Tatin to load/update/manage them as dynamically as needed. Of course, such a concept would be a significant enhancement to be considered for a later version of Tatin.

Think that might be worth a thought?

[e9gille]

I don't like the idea that you rely on "uninstalled" packages from an installation folder, as I said, it just confuses the concept of an installation folder.

Regarding your suggestion of using ⎕SE as a cache, that should already work, you ought to be able to use LoadDependencies with the target space being ⎕SE. Doing that would still require that you use aliases to resolve name conflicts, but feel free to try it out.

[DavinChurch]

I meant using LoadPackage for most everything instead of InstallPackage, so I didn't have an installation folder in the first place.

Thanks for the ⎕SE suggestion - I guess I hadn't put two and two together. I'll check it out.

[DavinChurch]

Ok, pre-loading packages in ⎕SE doesn't help much in my situation because I can't )SAVE the workspace if it contains references to ⎕SE. If I'm going to have to reconnect the packages every time I load then I might as well just put them in my WS every time. But that still means erasing them from the WS before every save (either to save space or disconnect ⎕SE links) and I SAVE frequently (even with SI where disconnections aren't really possible). So I'm still back to my original difficulties with too many WSes for me to manage.

Hmmm...