Merge lp:~ted/snapcraft/python-pip into lp:~snappy-dev/snapcraft/core
| Status: | Merged |
|---|---|
| Approved by: | Sergio Schvezov on 2015-09-18 |
| Approved revision: | 159 |
| Merged at revision: | 178 |
| Proposed branch: | lp:~ted/snapcraft/python-pip |
| Merge into: | lp:~snappy-dev/snapcraft/core |
| Diff against target: |
237 lines (+95/-11) 11 files modified
integration-tests/data/pip-requirements/icon.svg (+2/-0) integration-tests/data/pip-requirements/requirements.txt (+1/-0) integration-tests/data/pip-requirements/snapcraft.yaml (+14/-0) integration-tests/units/jobs.pxu (+11/-0) plugins/python2.yaml (+3/-0) plugins/python3.yaml (+3/-0) snapcraft/plugins/python2.py (+25/-0) snapcraft/plugins/python2_project.py (+2/-5) snapcraft/plugins/python3.py (+25/-0) snapcraft/plugins/python3_project.py (+5/-4) snapcraft/yaml.py (+4/-2) |
| To merge this branch: | bzr merge lp:~ted/snapcraft/python-pip |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Sergio Schvezov | 2015-09-14 | Approve on 2015-09-18 | |
|
Review via email:
|
|||
Commit Message
Add in support for PIP requirements.txt files in the python plugins.
Description of the Change
Add in support for PIP requirements.txt files in the python plugins.
| Sergio Schvezov (sergiusens) wrote : | # |
| Sergio Schvezov (sergiusens) wrote : | # |
hey this looks good, it just seems that py2 took a different path than py3.
This also removes the use case (which is rather neat) that the py2-project and py3-project examples bring in.
| Sergio Schvezov (sergiusens) wrote : | # |
python2 and python3 for pip is fine fwiw
- 150. By Ted Gould on 2015-09-14
-
Grabbin' trunk
- 151. By Ted Gould on 2015-09-16
-
Put PYTHONPATH in the overall environment instead of a custom one
- 152. By Ted Gould on 2015-09-16
-
Move PYTHONPATH to the env function in Python 2 as well
- 153. By Ted Gould on 2015-09-16
-
Switch python2 to use target as well
| Ted Gould (ted) wrote : | # |
So, some slight modifications. Switched from --root to --target as it seems in recursive cases that causes "bad things to happen" in that it appends twice. But target doesn't have that problem. Also moved the PYTHONPATH to the standard snapcraft environment handling. Now I can build a Nova snap:
https:/
Still would like to figure out if we can fix the command line support in setuptools to not put in the full path in a shebang, but that's not really a pip issue.
| Ted Gould (ted) wrote : | # |
On Tue, 2015-09-15 at 05:53 +0000, Sergio Schvezov wrote:
> hey this looks good, it just seems that py2 took a different path than py3.
>
> This also removes the use case (which is rather neat) that the py2-project and py3-project examples bring in.
<snip>
I was confused, I didn't see your comments in the diff... handled now.
Thanks!
| Sergio Schvezov (sergiusens) wrote : | # |
This is what I see when doing
cd examples/
../../bin/snapcraft
...
Building config
python3 setup.py install --install-
running install
Checking .pth file support in /home/sergiusen
/home/sergiusen
TEST FAILED: /home/sergiusen
error: bad install directory or PYTHONPATH
You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from. The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:
/home/
and your PYTHONPATH environment variable currently contains:
'/home/
Here are some of your options for correcting the problem:
* You can choose a different installation directory, i.e., one that is
on PYTHONPATH or supports .pth files
* You can add the installation directory to the PYTHONPATH environment
variable. (It must then also be on PYTHONPATH whenever you run
Python and want to use the package(s) you are installing.)
* You can set up the installation directory to support ".pth" files by
using one of the approaches described here:
https:/
Please make the appropriate changes for your system and try again.
Failed doing build for config!
| Sergio Schvezov (sergiusens) wrote : | # |
Thanks! This was a tough one!


Are you rendering the py3 and py2 examples useless here by removing handle_source options?
I also bring this question up often enough (internally at least); with this implemented in python instead of python-project, what is the reason for python-project (or any .*-project at all?)