Jump to content

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


Mariano Aristu
 Share

Recommended Posts

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...

Link to comment
Share on other sites

  • 2 weeks later...

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.

  • Like 2
Link to comment
Share on other sites

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?

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.