We Keep Coding

Python Poetry, install project into shell's namespace

What is a / the proper way to install Python programs into the shell's namespace via Poetry? With setuptools, you can use $ pip install -e path/to/project and then you can invoke $ project. However I have not found a way to do that with Poetry. Instead I need to use $ poetry run project.
To clarify, I want the following behavior:
$ poetry <some command> path/to/project
$ project
<output of project>

I guess your goal is to install your cli and make changes to it without having to reinstall it?
As you've probably noticed pip install -e doesn't yet support PEP 518 based projects like you get with poetry.
Poetry's solution for this is of course to let you execute installed libs or cli tools with poetry run as you described, or to activate the virtualenv that poetry creates containing your project in a new shell with poetry shell, which is similar to an interactive installation as long as your stay inside that shell.
Of course you can still install the project as usual with pip install ., and mess around with the files as the installed location, though this isn't a recommended workflow.

Python not recognizing virtualenv

First I run command pip install virtualenv then after I run python -m virtualenv venv, I get this following error msg
"/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenv"
Cuurently, I'm using python v2.7.16 and when I run pip freeze | grep virtualenv , I get virtualenv==20.4.2 so virtualenv is there. When I run which python I get /usr/bin/python and I don't have .bash_profile when I run ls -a. I am using mac. What could be the reasons python not recognizing virtualenv when it's there?

You may create .bash_profile and it is auto-recognised by the macintosh machine.
Please also run which pip and make sure the pip is in the same bin as your python (/usr/bin/python)
The bottom line is pip used to install a package by default will install the packages in the bin directory that also stored your python executable.

Python - Distributing Library With Source

I'm writing a program that uses some cryptography for a class. Since I'm low on time, I'd like to go with Python for this assignment. The issue that I run into is that the code must be able to work on the Linux machines at the school. We are able to SSH into those machines and run the code, but we aren't allowed to install anything. I'm using the Cryptography library for Python:
pip install cryptography
Is there a straightforward way that I can include this with my .py file such that the issue of not being able to install the library on the Linux machines won't be a problem?

You have few options:
virtualenv
Install into virtualenv (assuming command virtualenv is installed):
$ cd projectdir
$ virtualenv venv
$ source venv/bin/activate
(venv)$ pip install cryptography
(venv)$ vim mycode.py
(venv)$ python mycode.py
The trick is, you install into local virtual environment, which does not
requires root priviledges.
tox
tox is great tool. After investing a bit of time, you can easily create multiple virtualenvs.
It assumes, you have tox installed in your system.
$ tox-quickstart
$ ...accept all defaults
$ vim tox.ini
The tox.ini my look like:
[tox]
envlist = py27
skipsdist = true
[testenv]
commands = python --version
deps =
cryptography
then run (with virtualenvs being deactivated):
$ tox
it will create virtualenv in directory .tox/py27
Activate it (still being in the same dir):
$ source .tox/py27/bin/activate
(py27)$ pip freeze
cryptography==1.2.2
... and few more...
Install into --user python profile
While this allows installing without root priviledges, it is not recommended as
it soon ends in one big mess.
EDIT (reaction to MattDMo comment):
If one user has two project with conflicting requirements (e.g. different
package versions), --user installation will not work as the packages are
living in one scope shared across all user projects.
With virtualenvs you may keep virtualenv inside of project folders and feel
free to destroy and recreate or modify any of them without affecting any other
project.
Virtualenvs have no problem with "piling up": if you can find your project
folder, you shall be able to find and manage related virtualenv(s) in it.
Use of virtualenv became de-facto recommended standard. I remember numerous
examples starting with creating virtualenv, but I cannot remember one case
using $ pip install --user.

How do I use pytest with virtualenv?

I installed pytest into a virtual environment (using virtualenv) and am running it from that virtual environment, but it is not using the packages that I installed in that virtual environment. Instead, it is using the main system packages. (Using python -m unittest discover, I can actually run my tests with the right python and packages, but I want to use the py.test framework.)
Is it possible that py.test is actually not running the pytest inside the virtual environment and I have to specify which pytest to run?
How to I get py.test to use only the python and packages that are in my virtualenv?
Also, since I have several version of Python on my system, how do I tell which Python that Pytest is using? Will it automatically use the Python within my virtual environment, or do I have to specify somehow?

There is a bit of a dance to get this to work:
activate your venv : source venv/bin/activate
install pytest : pip install pytest
re-activate your venv: deactivate && source venv/bin/activate
The reason is that the path to pytest is set by the sourceing the activate file only after pytest is actually installed in the venv. You can't set the path to something before it is installed.
Re-activateing is required for any console entry points installed within your virtual environment.

Inside your environment, you may try
python -m pytest

In my case I was obliged to leave the venv (deactivate), remove pytest (pip uninstall pytest), enter the venv (source /my/path/to/venv), and then reinstall pytest (pip install pytest). I don't known exacttly why pip refuse to install pytest in venv (it says it already present).
I hope this helps

you have to activate your python env every time you want to run your python script, you have several ways to activate it, we assume that your virtualenv is installed under /home/venv :
1- the based one is to run the python with one command line
>>> /home/venv/bin/python <your python file.py>
2- add this line on the top of python script file
#! /home/venv/bin/python and then run python <you python file.py>
3- activate your python env source /home/venv/bin/activate and then run you script like python <you python file.py>
4- use virtualenvwrapper to manager and activate your python environments

Why do distribute and pip install to my virtualenv's ./local/bin?

I create and activate a virtualenv (venv) using Python 3.3's built-in way of doing it:
$ python3.3 -m venv env
$ source env/bin/activate
At this point python is the python in my virtualenv, which I expect:
(env) $ which python
/my_home_directory/env/bin/python
Now I want to install distribute and pip, so I download the setup scripts and run them:
(env)$ wget http://python-distribute.org/distribute_setup.py
(env)$ wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py
(env)$ python distribute_setup.py
(env)$ python get-pip.py
These commands complete successfully. At this point I inspect my venv to find another directory called "local" which wasn't there before. env/local/bin contains my easy_install and pip executables, and they're still aliased to my system's existing easy_install and pip:
(env)$ ls env
bin include lib local pyvenv.cfg
(env)$ ls env/bin
activate pydoc python python3 python3.3
(env)$ ls env/local/bin
easy_install easy_install-3.3 pip pip-3.3
(env)$ which easy_install
/usr/bin/easy_install
(env)$ which pip
/usr/bin/pip
I believe this is a departure from Python 2.x's behavior. At this point I expect easy_install and pip to be using the virtualenv's copies, and using them to install eggs will put them in the virtualenv.
Going a bit further, I crack open env/bin/activate to find that env/bin is prepended to the system path, but env/local/bin is not. That explains the behavior I'm seeing. I can work around this problem by editing env/bin/activate to add the env/local/bin directory to the path, something like:
_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/bin:$PATH"
PATH="$VIRTUAL_ENV/local/bin:$PATH" # my new line
export PATH
So, what's going on here? Is this a bug, or am I missing something?
I'm on Ubuntu 12.10 in case that makes a difference.

I have a feeling there's a bug in Ubuntu's python packages or distribute somewhere… but I haven't tracked it down (and I'm not sure I care to).
For whatever reason, the VIRTUAL_ENV environment variable needs to be set the root of the virtualenv for distribute and pip to install properly.
This gist, adopted from Vinay Sajip's code sample in the Python 3 docs, sets said variable; both distribute and pip will install properly when using it.

It's in the python docs.
'/usr/local' is the default exec_prefix. Read the venv docs for detail how to change the default behaviour. There's even an example there that shows how to make a venv.EnvBuilder that installs distribute and pip for you.
if you find distribute docs, please let me know ;-)

I had the same problem.
In activate script file I need to add as first line (of cource after #!...):
unset PYTHON_PATH