0

Suppose I have a set of scripts and a python environment that supports them and their dependencies.

I would like to automate the activation of the python environment so that, for my particular use case, the user's .bashrc/.zshrc gets updated so as to "source" the python environment.

What is the correct/debionic way to handle this issue that won't raise red flags or eyebrows when the content is pushed into the home directory .bashrc files?

  • 1
    explain why you need to change the users environment when they are not using the scripts. it seems to me you need only wrap the scripts in something that prepares the execution environment as needed. – Jasen Sep 21 '19 at 3:13
  • Frankly, it isn't for a user, in the worst case scenario; it could just be for a container that I attach the user to with a shell script. But, ideally, the user can dpkg -i the thing and have both the binaries and python scripts working, without any extra legwork. I don't want to interfere with their python setup, so I have packaged the env in the opt folder. But they'll still need to source activate it. – Christopher Sep 21 '19 at 3:15
  • @Jasen But it would be nice to have some go to protocol or something along these lines for linking the project to the user who installs it... In any case: it is simply a matter of how to you deliver something to someone who may not be computer literate enough to get something like this to work after installing it? It needs to be very streamlined. – Christopher Sep 21 '19 at 3:17
  • @Jasen I'll do that for the docker container then, and see about alternatives for the one-command "it works" issue – Christopher Sep 21 '19 at 3:21
  • if it's a debian package the "user who installed it" is root. – Jasen Sep 21 '19 at 3:24
2

Global shell settings go in /etc/profile.d but I'd advise against modifying every users environment away from standard.

It would seem better to add the needed python packages to the default envronent instead, or to invoke the special envronment only when needed.

| improve this answer | |
  • I could probably have the user "source foo", where foo is shell symlinked in /usr/bin to start up the env. Something like that? – Christopher Sep 21 '19 at 3:25
  • 1
    just have a wrapper script for the feature that does source foo then execs the feature command, move the feature command to /usr/bin/lib and have the wrapper in /usr/bin – Jasen Sep 21 '19 at 3:28
  • the scripts are all interchangeable as piped commands (they have a pipe mode) and an arg based execution mode. Is wrapping them in shell scripts not going to introduce stdin complexity here? – Christopher Sep 21 '19 at 3:30
  • in other words, are you saying that this will work -- having the "source foo" command before any of the python programs are executed by the user -- but that I should organize it that way? OR that i should wrap every python program in a shell script that execs the python program after sourcing the env? – Christopher Sep 21 '19 at 3:33
  • 1
    @donlan Note that you don't need more than one wrapper script. Just one with multiple hard or soft links will do as long as the wrapper script examines $0 and takes different actions depending on how it is invoked. – cas Sep 21 '19 at 10:13
3

There is none. Packages do not mess with the home directories of users. It would be best to include an initialisation script in your package that adds the relevant content to the correct file, that is then called on first run of the other scripts.

| improve this answer | |
  • 1
    An initialisation script AND document the environment variables etc that need to be set. If you have to choose between one or the other, choose the documentation. Assume your users are not complete morons and can follow written instructions. Assume they're also not mind-readers and need those instructions. – cas Sep 21 '19 at 10:08
  • 1
    BTW, with well-written comments, an initialisation script can double as documentation. Install it under the /usr/share/doc/packagename directory where it belongs. – cas Sep 21 '19 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.