You’d be changing the frappe-bench executable package, but not your working directory (also called bench). In other words, it shouldn’t blow anything up, but of course always take backups, test on staging, etc., etc.
I don’t know much about the install.py process, but on quick search in the source code it doesn’t look like it.
@kennethsequeira , I am using the install.py script to do production installs and they are coming out this way. I am not a developer and am very unsure of how to get a valid install without this warning.
Could it be the developer team chose this way to install bench in order to get around having to otherwise install it 2 times (once from the user account and once as ‘sudo’)??
I do know that installing a production server in single steps, you have to install bench 2 times in order to get it to work. the second time as a sudo user. Otherwise things begin to fail when you start to use the system.
However, I am also not comfortable installing is such a manner that bench could be edited locally.
So, what is the correct way to install bench JUST ONE TIME and still have a valid working production install?
I ran into this several months ago. It first appeared in this post as steps #15 and #16 in the 22 steps to getting a working v13 beta server by @adals :
I even had to include it in my own rendition of the same process for making a v13 production server work otherwise I could not perform certain bench functions.
Then I had an offline conversation with another user/developer about this very problem and after much experimenting we could not find any other way to keep bench working properly for ALL functions unless we installed it twice!
There is a short discussion of that very problem in this post on yet another thread. Ultimately it was determined that you could either run bench in editable mode or else you had to install it twice. Neither is real;ly a satisfactory answer to running a secure version of bench. Here is the discussion on that part of the story:
So, @peterg if you have an alternate solution we are all waiting patiently for the fix.
This is the reason I tagged you back on the correction you suggested about how best to install bench. Your method leave bench partially unusable unless it is installed twice as discussed in the above link.
Unless bench is additionally installed as a sudo user then you will never be able to use some of the following commands:
sudo bench setup lets-encrypt
This is needed in order to get your SSL certificate from Let’s Encrypt
sudo bench --force --site site1.local restore /path_to_sql_file
And this is the specified way for restoring a database to your ERPNext server.
There are a few others as well, but unless you have bench installed as a sudo user in addition to the regular user, you cannot perform several critical tasks. There must be a better way than using the bench in editable mode.
Still looking for a better solution. Does anyone have a fix for this?
I simply install certbot, and use sudo certbot --nginx
I don’t know if pip3 install frappe-bench would work to install bench in your case, my guess is it will work. I also think uninstalling bench using pip is NOT needed in your case because you did not use pip to install bench in the first place.
I cannot verify my suggestion here because I no longer use the EASY INSTALL method anymore.
It sounds like a path issue. The fix will likely be slightly different depending on your distro and method of installing python3.
Do you still get the same problem if you use an absolute path to bench? Have you tried installing globally like @snv recommends in the thread you’ve linked? If those don’t work, you might also try passing your path variable to sudo (sudo env PATH=$PATH bench).
I’ve never seen this issue before, but that might be because of the distro I use. Ubuntu is a bit quirky in how it maintains environment variables in sudo commands, though I’ve heard the behavior changed at some point in version 19. CentOS does it differently still, I believe. Unfortunately, this is stuff that the bench maintainers have very little control over. That might be why they’re still installing direct from repo in the install.py script.