Skip to content
This repository has been archived by the owner on Sep 19, 2022. It is now read-only.

Enhancement - Application Installation Conforms to XDG Specification #62

Closed
c-nv-s opened this issue Feb 19, 2021 · 6 comments
Closed
Labels
enhancement New feature or request
Milestone

Comments

@c-nv-s
Copy link
Contributor

c-nv-s commented Feb 19, 2021

As an administrator installing pglet, I would like to have the flexibility to determine my own location e.g. /usr/local/bin/ for the application binary and any application data to be installed (respecting my permissions).

The value added would be that it gives me the control to organize binaries and application data on my operation system according to my own desire or to conform to constraints placed on me by a third party.

A simple solution would be that the installation script would check an environment variable e.g. $PGLET_INSTALL_DIR is set, and install to that location, and if it is not set then it falls back to the application developers chosen location.

The only implication with this is that in future if any user-specific files are needed by pglet then it should look for them from standardized locations and again fall back if needed. as a suggested solution pglet installations could conform to the XDG base dir standard ( see freedesktop.org or the arch wiki )

so for example it could check:
$XDG_CONFIG_HOME/pglet/
$XDG_DATA_HOME/pglet/
$XDG_CACHE_HOME/pglet/
and fall back as necessary.

@FeodorFitsner
Copy link
Contributor

Right, at the moment it's only a single executable. Customizing installation directory with $PGLET_INSTALL_DIR makes sense.

Re: XDG standard - do I correctly understand that $XDG_CACHE_HOME is not set by default on Linux installation or how is it being set?

@FeodorFitsner FeodorFitsner added the enhancement New feature or request label Feb 19, 2021
@c-nv-s
Copy link
Contributor Author

c-nv-s commented Feb 19, 2021

you are correct,
I don't think any of the variables are set by default ( with the exception of $XDG_RUNTIME_DIR which might be set by some systems )
If I understand the purpose of the spec it is to allow the user to set those environment variables themselves if they wish customize the installation locations, and it just gives app developers standard environment variable names to check and install to for common types of files used in app development or otherwise fall back to whatever they want if the user didn't choose a custom location.

@FeodorFitsner
Copy link
Contributor

OK, what I'm going to do is to add support for $PGLET_INSTALL_DIR environment variable. Whenever user specifies $PGLET_INSTALL_DIR it's assumed it's added in $PATH already (or will be added), so PGLET_INSTALL_DIR=/usr/local/bin/ is a good candidate.

While looking for pglet executable pglet.sh will be checking $PATH first. If pglet executable is found in any $PATH directory the script will check the version of that executable. If pglet needs to be upgraded then a newer version will be downloaded to (in order of priority) 1) the same directory as current pglet if $PGLET_INSTALL_DIR is not specified, 2) to $PGLET_INSTALL_DIR if it's specified, old pglet removed from current dir, 3) to ~/.pglet/bin otherwise as a fallback.

@FeodorFitsner
Copy link
Contributor

OK, I've updated https://pglet.io/pglet.sh and the docs: https://pglet.io/docs/tutorials/bash#installing-pgletsh - let me know how it works.

@c-nv-s
Copy link
Contributor Author

c-nv-s commented Feb 20, 2021

I've suggested minor updates:

pglet/pglet-bash#3

and slight change to the example install command to use export

pglet/website#10

... It might also be good to amend the NOTE in the docs to say that it is assumed $PGLET_INSTALL_DIR has precedence in the user's path! because if for example an admin were to arguably install pglet in /usr/local/sbin this location in the path is usually before /usr/local/bin so the script will be trying to replace the pglet binary found in the first location in the users path. and fail if the user doesn't have permissions.

@FeodorFitsner
Copy link
Contributor

Great, thank you!

@FeodorFitsner FeodorFitsner added this to the v0.2.3 milestone Feb 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants