I have a Python app that I use locally that needs to be launched via pipenv run python3 appname.py in order to load virtual environment with installed dependencies. This is all on macOS.
What I want to achieve is to be able to run this app from anywhere with $ appname [args].
So what I did was:
add #!/usr/bin/env pipenv run python3 to appname.py;
make that file executable with chmod +x appname.py;
make symlink with ln -s /path/to/appname.py ~/.bin/appname;
put ~/.bin on my $PATH.
Now when I launch $ appname, pipenv creates a new virtual environment in the ~/.bin folder and complains about missing dependencies, all instead of following through into the actual location of the script.
Is there a way to overcome this? Or maybe a better way to achieve what I want?
For my purposes a more sensible thing to do was freezing my code by packaging it (along with all dependencies) into an executable with pyinstaller.
What I did was:
Installed pyinstaller as dev dependency with pipenv install --dev pyinstaller;
Launched pipenv shell in the project directory;
Packaged the app with pyinstaller --onefile appname.py;
Moved the resulting self-containing [project path]/dist/appname executable into my ~/.bin directory.
There were some unrelated issues to overcome, but otherwise worked perfectly for me.
Related
I'm trying to run a pyinstaller-built executable on another machine. The error I see is Error loading Python DLL 'C:\Users\User\AppData\Local\Temp\_MEI70722\python39.dll
I built the program like this, I also added -F to make sure the executable is standalone:
py -m PyInstaller script.py -F
I tried adding --add-binary and --add-data options with the path to python39.dll, but that didn't help.
The program is built on Windows 10 x64, the machine I'm trying to run the program on is Windows 7 x64. Even with such a difference and the fact that Python 3.9 is not for Windows 7, I really doubt this is the reason, otherwise I would expect another error.
What am I doing wrong?
Ok so here's solution that worked for me:
Install a Windows7-compatible version of python3. I did this from the Windows Store, which made it accessible in my command line as "python3."
Set up a virtual environment with your downgraded version of python. On command line, that's
...> python3 -m venv my_env
In command line, navigate to your newly created environment directory, and use pip to re-install pyinstaller in your new environment:
...> cd my_env
...\my_env> pip install pyinstaller
From command line in my_env, use pyinstaller to compile your code. You should probably move script.py into your my_env directory.
...\my_env> pyinstaller script.py -F
I was able to copy the standalone script created in \my_env onto a Windows 7 machine and run it successfully. Hope this helps!
I am running Gitbash for windows and have installed pipenv using pip. Yet when I invoke pipenv nothing happens:
Since there isn't a command not found error, I believe the script is recognized it just isn't running properly.
Pipenv is installed globally:
I also can confirm that the Scripts folder is in the file path:
I don't think it is a problem with Gitbash because I can run other pip packages in the same scripts folder:
I'm also able to run python pipenv.exe but not pipenv.exe when in the Scripts folder:
I've struggled with this myself untill just now.
I've got a few suggestions.
SOLUTION 1:
I was calling Poetry to try and make sense of it as well and then I tried calling both applications from Powershell. Both work as inteded.
SOLUTION 2:
Calling python -m pipenv, as sugested in this other Stack Overflow thread, also works as intended. You could alias the command to pipenv in git bash and call it a day too.
Quoting the docs on the -m flag:
When called with -m module-name, the given module is located on the Python module path and executed as a script.
Quoting appdividend.com:
The -m flag in Python searches the sys.path for the named module and executes its contents as the __main__ module.
It goes through whatever path is in which pipenv and executes the module as a script.
SOLUTION 3:
This is how I ended up fixing my Pipenv blunder.
Reinstall Python and all packages to AppData.
MINGW64 was having trouble seeing Pipenv in C:\Program Files. I also noticed that I had some packages in AppData\Roaming as well, so I figured I'd reinstall Python, unticking the Install for all users option (to trigger AppData installation) to see if I could wrangle all packages together.
After that I tried installing Pipenv and succeeded in calling it as expected.
This is all highly anecdotal. I have no idea why MINGW64 failed to call JUST Pipenv and not Poetry, but this is how I've fixed it on my end.
I've been making a python project using pipenv, and I want to be able to run it in a terminal from any location on my (linux) system.
Specifically, say I have the following directory structure:
/home
/project
Pipfile
main.py
/other_dir
I would like to be able to make an alias that allows me to call main.py like so:
/home/other_dir$ alias_to_my_proyect --some args
and run it in the virtual env, having the same behaviour as
/home/project$ pipenv run python main.py
But in another directory.
If it weren't a pipenv project, I'd just use a shebang a the start of the file and then add an alias to it in my .bashrc, but I want to use pipenv's virtual environment, but I cant find a way to do this with pipenv.
If you want to use a specific python environment for your script you will need to point it to the interpreter of that environment. On Mac the default is that pipenv installs all virtualenvs to /Users/<user_name>/.local/share/virtualenvs/ however that can be set to different locations as described in the manual:
Pipenv automatically honors the WORKON_HOME environment variable, if you have it set — so you can tell pipenv to store your virtual environments wherever you want, e.g.:
export WORKON_HOME=~/.venvs
In addition, you can also have Pipenv stick the virtualenv in project/.venv by setting the PIPENV_VENV_IN_PROJECT environment variable.
You can find out where the exact location of the virtualenv is with pipenv --venv inside your project folder. It returns something like /Users/reedef/.local/share/virtualenvs/project-BpR9WgCa. The interpreter is in ./bin/python of that location.
If we assume that you did not set any environment variable and you are using Mac than that means that you can write a script:
#!/usr/bin/env sh
/Users/reedef/.local/share/virtualenvs/project-BpR9WgCa/bin/python /home/project/main.py
and place it somewhere in your $PATH, e.g. /usr/local/bin/my_fancy_main to let it run in that specific environment.
Note: as mentioned by #Jon in the comments, -BpR9WgCa at the end of the path is stable as it is made from the project path:
hash = hashlib.sha256(location.encode()).digest()[:6]
It should be the same as long as the project path hasn't changed.
You can just use
#!/usr/bin/env pipenv-shebang
in your script after you install my pipenv-shebang package:
pip install pipenv-shebang
You should use the standard setuptools library to write a setup.py file. In particular you can write an entry_points section that names your main script:
entry_points={
'console_scripts': [
'alias_to_my_project = project.main.main'
]
}
Once you've done this, you can activate and install your package into your virtual environment
pipenv install -e .
# or without pipenv
. ~/vpy/bin/activate
pip install -e .
This will create a wrapper script in $VIRTUAL_ENV/bin/alias_to_my_project that loads the project.main Python module and calls its main function.
The wrapper script knows about the virtual environment and can be called directly without specifically activating the virtual environment. So you can do something like
ln -s $VIRTUAL_ENV/bin/alias_to_my_project $HOME/bin/alias_to_my_project
PATH=$HOME/bin:$PATH
and it will always be available.
I'm following the Flask Mega Tutorial from http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world/page/0
I have created the project folder as told, and created the virtualenv using "mkvirtualenv flask" and used "workon flask" to activate it.
After that the tutorial asks to run some commands to install the dependecies of the project running "flask/bin/pip install " but when I try it I get the following error: "bash: flask/bin/pip: No such file or directory". (I believe that's because the folders created for the venv, are not on the folder but on ~/.virtualenvs).
So I istalled the dependecies using "(flask)$ pip install "
then I created the files and folders for the project as told, and when I try to run the project I get: bash: ./run.py: flask/bin/python: bad interpreter: No such file or directory
If I run "python run.py" looks like the project is running, but notthing happens, and i get no message saying that the project is running on any port, just this:
Restarting with stat
Debugger is active!
Debugger pin code: 284-703-124
can anyone help me pls?
(i'm running on ubuntu 14.04lts)
Don't know if this will help but this is how I solved my config issues for The Flask Mega-Tutorial on Mac OS 10.11 El Capitan.
Start from scratch removing all files and folders you've been working with
Follow the Flash install guide on the website http://flask.pocoo.org/docs/latest/installation/
Using the steps in the link above as follows:
$ sudo easy_install virtualenv
$ mkdir myproject
$ cd myproject
$ virtualenv venv
$ . venv/bin/activate
$ pip install Flask
3. Use the $ pip install Flask format for all the items Miguel lists in the $ flask/bin/pip install flask format
$ mkdir app
4. Make the necessary files for the Hello, World! example: app/__init__.py,
app/views.py, a
run.py
Note: in run.py you will need to change the first line from #!flask/bin/python to #!venv/bin/python
5. Run it
$ chmod a+x run.py
$ ./run.py
If you're running "python run.py" and getting this output...
Restarting with stat
Debugger is active!
Debugger pin code: 284-703-124
...then the flask project actually IS running. You've got it working - it just doesn't tell you that in the output above. Open a browser and navigate to http://localhost:5000, though, and you should see the test site up and running.
The problem is that in the tutorial, it assumes you have not activated the virtual environment, and you are still in the parent directory where the virtual environment was created.
That's why the commands are all prefixed with flask/bin/pip; flask is the directory where the virtual environment was created.
Once you create a virtual environment you usually follow this up with the activate script. All this script does is changes the paths so commands like python and pip point to the virtual environment's bin folder rather then pointing to the default system location. It also adds a variable to the shell so that programs can detect they are running in a virtual environment, and it adds the name of the virtual environment to the prompt.
If you don't activate the virtual environment, you can still install packages in it by giving the full path to the pip command that is in the virtual environment. Due to the way Python works, it will install packages inside the virtual environment (since that's the first package directory it will find). This is what is happening in the tutorial.
So if you activated the virtual environment, remove flask/bin/ from the instructions and use the commands directly.
I'm a newbie to Python and I've spent hours on this. I can't seem to figure out why when I run a simple command to setup my Python environment: virtualenv --distribute env
This doesn't create a bin file in the env directory.
It only creates:
-- env
-- Include
-- Lib
-- Scripts
My impressions was that a bin directory would be created per a lot of the examples I've found on the web (e.g. I'm not able to run this command: env/bin/activate).
I'm using Windows 7 and Python 2.7.
On Windows, this is entirely correct. A bin directory is created on POSIX systems only. From the Windows Notes section of the documentation:
Some paths within the virtualenv are slightly different on Windows: scripts and executables on Windows go in ENV\Scripts\ instead of ENV/bin/ and libraries go in ENV\Lib\ rather than ENV/lib/.
For Windows, run \path\to\env\Scripts\activate to activate the virtualenv. From the documentation again:
On Windows you just do:
> \path\to\env\Scripts\activate
And type deactivate to undo the changes.
Based on your active shell (CMD.exe or Powershell.exe), Windows will use either activate.bat or activate.ps1 (as appropriate) to activate the virtual environment.
If you're using Git Bash for Windows, I found the following command works to activate the environment: $ source (path to environment)/Scripts/activate
I was using Git Bash on Windows 10, Python(v3.7), Pip (v19.0.3), virtualenv (v16.4.3)
Yes, correct. On Windows, it creates the directory hierarchy as follows:
venv (virtual environment name)
Include
Lib\site-packages
Scripts
Just like in this image:
.
For windows , you have to run python -m venv <your_env_name> and
source <your_env_name>/Scripts/acivate.
This works for me on windows.