feature request Feature idea: add in VI package builder at install requirements where the package can be installed

[Mariano Aristu]

I would include an option at install requirements page indicating if the package can be only installed on the global environment, local environment or both.

[kosist]

That would solve the issues of installing project providers, quick drops, etc. into local environment... But also it would be nice to set somehow such option without package rebuild (in order to update existing packages available online) - maybe it could be possible to set it via vipm.io. VIPM downloads packages from repository, so it could check permissions which are set for the particular package directly in the repository...

[Steven Dusing]

I would like to see VIPM be smart enough to know to put project providers, quick drops, etc into the global environment for us so that we don't need to rebuild existing packages (or hope that others update their packages).  VIPM should know from the build spec where it's going to put file.  If VIPM can simply differentiate between locations that only work well in the global environment vs custom or standard locations for source code (vi.lib, user.lib, etc), that would take the burden off of everyone to make the decision, as it would be handled automatically.

[Jim Kring]

Hi @Mariano Aristu, @kosist, @Steven Dusing.

Thanks for the great idea and discussion. You're right that it needs to be easier for end users of packages to install packages and have them end up in the right (global vs local) locations.

We're considering the options, which include the one's you've mentioned:

A.) A setting inside the package (Pros: the package builder knows best and has more control, relatively simple to implement; Cons: requires rebuilding and redistributing the package)

B.) Making VIPM smarter so that it can tell by looking at the package contents and where things are installed (Pros: would "just work" without having to rebuild packages or add more meta info to the repositories, Cons: Requires a lot of dynamic package contents/rules checking to determine where packages can/should be installed) 

C.) Making the repository aware of the setting for the package, so that packages do not need to be rebuilt (Pros: Doesn't require rebuilding packages, doesn't require smarts in VIPM; Cons: Requires extending the repo format and VIPM to use it, requires someone other than the package developer to define this setting, doesn't work for users who are off-line and don't have access to the repository).

Based on this, it seems like option (A) adding a flag/setting in the package builder is a good one and also is compatible with (B) adding more smarts to VIPM in the future.

Another other options or thoughts around this?

[Steven Dusing]

@Jim Kring For option A, if a package is built with these settings configured at build time, and someone downloads the package but doesn't have Dragon or is perhaps using an older version of VIPM, will VIPM ignore these settings and install as it does in the current released version of VIPM?

[Jim Kring]

3 minutes ago, Steven Dusing said:

@Jim Kring For option A, if a package is built with these settings configured at build time, and someone downloads the package but doesn't have Dragon or is perhaps using an older version of VIPM, will VIPM ignore these settings and install as it does in the current released version of VIPM?

Yes, that would be the idea -- the flag would simply tell VIPM that global installation is required and the package cannot be installed into a virtual environment. So, if the package is not being installed by Dragon into a virtual environment, then it will be effectively ignored.