Removal of superceded packages

[DavinChurch]

I had an unexpected thing happen, and though it was intended by design I think the behavior should be changed.

Scenario: I installed a test package Tester-0.1.0 and tried it out. Then I added Tester-0.2.0 (in addition to the previous version) and tried it out. All looked fine so I left both versions installed and moved on to installing and checking FilePlus-0.1.0. I wanted to make some changes there so I uninstalled FilePlus-0.1.0 in preparation for building a new version. It did uninstall FilePlus-0.1.0 but it also uninstalled Tester-0.1.0 at the same time!

Neither of these packages have any dependencies nor is anything else dependent on them. Tester-0.1.0, even though it was a principal package, was removed simply because a newer version existed. However, I contend that this behavior is improper and should be changed.

I can see how 0.1.0 might be needed in one application or sub-application while 0.2.0 is simultaneously needed in another. Tatin should not make the assumption that since I now have 0.2.0 I shouldn't need 0.1.0 any more. It may well be mistaken. Only the user knows whether or not they still need that version installed. Therefore, only the user should be in control of uninstalling principal packages, even if a newer version might be available. Let the user uninstall 0.1.0 themselves if they decide they don't need it any more.

[DavinChurch]

If the "installed packages" list is left containing the older package definition with the "principal" flag left on when a newer version is installed, then it should be a simple matter to never delete prinicipal packages unless expressly commanded.

[aplteam]

You cannot install different versions of the same package and use both of them unless you assign an alias to one or both of them. That's by design, and I cannot see that this is going to be changed.

If you do assign an alias then both will survive a re-install, and you can load both in parallel.

However, at the moment when there is a package group-name-1.0.0 installed and there is now also a version group-name-1.1.0 available then a re-install will remove 1.0.0 and install 1.1.0 instead.

I now realize that this is not necessarily appreciated. I am going to change the default behaviour: in the future a re-install will always use the precise same version.

If one wants to use re-install in order to update all packages to the latest versions available then the newly introduced flag -update will do the trick,

To be implemented in version 0.53.0

[DavinChurch]

I don't think this applies to my original comment because I wasn't doing a re-install. The original problem was an un-install.

[aplteam]

Yes, but the principle is the same. You cannot install the same package several times and use them. You can only use the latest one. So in your scenario whether Tester-0.1.0 is installed or not, after the installation of Tester-0.2.0 it cannot be used, so there is not point of it being around.

You must assign an alias to at least one of them to avoid the name clash, and once you do that it won't be un-installed.

[DavinChurch]

So I can't have package AAA dependent on Tester-0.1.0 and BBB dependent on Tester-0.2.0 at the same time, at all?

That sounds like a danger if Tester-0.2.0 has an inadvertent bug in it that AAA exposes and it needs to use the older version until it's fixed, while BBB needs features only available in the newer version. What then?

[aplteam]

Oh no, that's a misunderstanding: I was referring to principal packages.

[DavinChurch]

My apologies - I described that poorly. I should have said workspace AAA and BBB, since that's how I was thinking about using it. Of course, that also means that AAA and BBB are sharing the same installed area.

[DavinChurch]

I still don't like the idea of Tatin doing things that I didn't tell it to do, either, especially to completely unrelated packages. I always have disagreements with any software that thinks it knows what to do better than I do and doesn't give me any choices. I wouldn't like for Tatin to join that group. A system should do things FOR me, not against me.

[aplteam]

Okay, in the next version (after 0.53) I am going to change this.

• The user command will print warnings
• The API function will add information regarding superfluous packages on the message it returns.

Both the user command (-prune) as well as the API function (additional flag) will allow the user to enforce the removal of such packages.

That means the default behaviour is as you suggested but you can make Tatin remove such packages if you wish so.

[DavinChurch]

Thanks - giving me the option is much better!

[e9gille]

I'm late to the discussion here, but starting to get a better picture of the environment you work in @DavinChurch.

Tatin was designed to make it easy to use packages and we spent a lot of time considering the various strategies of loading dependencies. During the design discussions we saw Tatin as a package manager primarily for a context like a session or a project of some sort (an application or another tool distributed as a package). There are package managers that have a system context, so they make it easy to install applications or libraries on a machine, but that wasn't our goal.

To make the context flexibel, we settled on the concept of installing packages in a folder. That folder could then be loaded into the context. What we didn't consider was that the same folder would be used for different contexts with different requirements. The current design requires separate folders for different requirements. The folder also contains a configuration file describing how it will be loaded into the target context.

If I follow the thread correctly, you want to use a single folder for different contexts and dynamically define the requirements at load time. Essentially use Tatin to install packages into a single folder with no specific context in mind (something like a download manager) and then provide the list of dependencies dynamically when loading into a given workspace.

If that is the case I would like to understand what the advantage is of installing the packages into the folder in the first place. You could load packages dynamically without first installing them in a folder, although with the current implementation that would probably be very inefficient. But if this is the case I would argue that we should look at how to make this more efficient by using a cache of some sort.

What is the reason you use a single folder and not separate folders for each context?

[DavinChurch]

See my comment in the correct thread, but I think perhaps I'm using things in a more simple manner than you're considering here.

[aplteam]

Since there is no way to archive a discussion, or mark it as obsolete or whatever, I am going to lock this discussion.

That allows you specify is:unlocked in order to filter it out.