Compare commits

...

2 Commits

Author SHA1 Message Date
Jordan Sissel 399dca6e9c Fix failing test.
Looks like at some point django changed the admin tool from
"django-admin" to "django-admin.py"

Possibly this changed in upstream in Django on this commit, though I
don't know for certain:
85efc14a2e
2022-05-01 21:47:40 -07:00
Jordan Sissel 69f45e7437 Run `pip` without the `--build` flag
Previously, fpm would use `pip download ... --build ...` to instruct pip
to unpack a given python package to a specific directory for the purpose
of running something like `python setup.py` from it.

However, somewhere in 2021, pip removed this flag. First, I think, it
was deprecated and ignored, then finally removed. One reference to
this removal in the upstream pip project is this issue:
https://github.com/pypa/pip/issues/8333

Without `--build`, pip will place a single tarball in the destination
directory. Fpm cannot easily predict the name of this file because we
don't know the "real" name of the python package nor do we know the
version number being downloaded.

For example:

```
% python3 -m pip download --no-binary :all: --no-deps --no-clean django
...
Successfully downloaded django
% ls
Django-4.0.4.tar.gz
```

Best guess:
* we can expect exactly one file in the previously-empty target directory
* we can also expect that it is a .tar.gz

I don't know if these guesses are always correct, but it's a start.

As of this commit, the following command generates a Debian package:

`fpm -s python --python-bin python3 -t deb django`

Prior to this commit, with a newer version of pip, the command would
fail.

Fixes #1831
2022-05-01 16:47:03 -07:00
2 changed files with 16 additions and 7 deletions

View File

@ -162,13 +162,22 @@ class FPM::Package::Python < FPM::Package
] ]
end end
setup_cmd += [ setup_cmd << want_pkg
"--build",
target,
want_pkg,
]
safesystem(*setup_cmd) safesystem(*setup_cmd)
# Pip removed the --build flag sometime in 2021, it seems: https://github.com/pypa/pip/issues/8333
# A workaround for pip removing the `--build` flag. Previously, `pip download --build ...` would leave
# behind a directory with the Python package extracted and ready to be used.
# For example, `pip download ... Django` puts `Django-4.0.4.tar.tz` into the build_path directory.
# If we expect `pip` to leave an unknown-named file in the `build_path` directory, let's check for
# a single file and unpack it. I don't know if it will /always/ be a .tar.gz though.
files = ::Dir.glob(File.join(build_path, "*.tar.gz"))
if files.length != 1
raise "Unexpected directory layout after `pip download ...`. This might be an fpm bug? The directory is #{build_path}"
end
safesystem("tar", "-zxf", files[0], "-C", target)
else else
# no pip, use easy_install # no pip, use easy_install
logger.debug("no pip, defaulting to easy_install", :easy_install => attributes[:python_easyinstall]) logger.debug("no pip, defaulting to easy_install", :easy_install => attributes[:python_easyinstall])

View File

@ -204,7 +204,7 @@ describe FPM::Package::Python do
# Hardcode /usr/local/bin here. On newer Python 3's I cannot figure out how to # Hardcode /usr/local/bin here. On newer Python 3's I cannot figure out how to
# determine the script_dir at installation time. easy_install's method is gone. # determine the script_dir at installation time. easy_install's method is gone.
path = subject.staging_path("/usr/local/bin/django-admin.py") path = subject.staging_path("/usr/local/bin/django-admin")
# Read the first line (the hashbang line) of the django-admin.py script # Read the first line (the hashbang line) of the django-admin.py script
fd = File.new(path, "r") fd = File.new(path, "r")