> ImportError: cannot import name 'Meta' from 'docutils.parsers.rst.directives.misc' (
This commit tries to resolve this by removing the 'docutils<0.18'
requirements entry.
This removes a warning in 3.4.0 and prepares for Ruby 3.5.0:
> warning: ostruct was loaded from the standard library, but will no longer
> be part of the default gems since Ruby 3.5.0. Add ostruct to your Gemfile or gemspec.
This seems preferable to adding ostruct as a gem dependency especially
since older rubies may not support the gem version of ostruct.
* --python-obey-requirements-txt behavior and tests. I swear this was
working previously but the tests failed.
* Now supports packaging local python project directories containing
a pyproject.toml
* amqplib 1.0.2 downloads a file ending in .tgz instead of expected .tar.gz
* dnspython 1.15.0 has METADATA which includes a description body, but
the metadata version is 2.0, and python core-metadata docs indicate
v2.1 added support for description body. In this case, if the metadata
version is 2.0, fpm now accepts a description body.
Reference: python core-metadata:
> Changed in version 2.1: This field may be specified in the message body instead.
Original report and fixes for this by @bugfood in #2002.
I hope this works? It works on my machine... :\
virtualenv and virtualenv-tools seem to be lesser-used these days. I
wonder if it'll be more useful to move to a different tool like venv...
Not supported yet:
* Custom environment for marker evaluation.
* "extras" markers
Restore function to `--python-obey-requirements-txt`. This flag will
only work on python inputs that are provided as a directory, not a
wheel/tar.gz/etc.
Tests pass including the obey requirements.txt ones.
* Fix bug 'else File.directory?` -> `elsif File.directory?...` lol oops.
* Use Dir.entries instead of Dir.glob to allow python package extra
syntax, with names like `django[bcrypt]` (Note, extras in requirements
aren't evaluated yet)
Working: Most python tests except for the --obey-requirements-text one
Breaking: Broke support for requirements.txt, for now.
* Deprecate --python-install-{bin,data,lib} flags since those are only
supported by setup.py. `pip` just supports `--prefix` and maybe that's ok.
* Deprecate --python-scripts-executable for similar reasons. I don't
think pip supports this?
* Add notes about unsupported Python dependency markers
* PythonMetadata is now a class with accessors providing name, version,
requirements, homepage, maintainer, etc.
* Moved package url/homepage selection into PythonMetadata
* Fix bug where dependency list would have trailing spaces.
* Updated test suite with new python package name prefix selection
(detecting python3, etc)
(Note: Not all parts of the metadata are used, and some could be used
that are not yet used...)
* Add more tests for parsing and PythonMetadata members
* maintainer: Use Maintainer-email if present, otherwise use Author-email
* license: Try the best field for using as the license label
(License-Expression, License, or a Classifier entry)
* homepage: Try to pick the right value for the homepage, or close
enough, since python packages can have multiple urls as project urls.
Parsing Python METADATA files:
* Treat any 'multiple use' fields (as documented in the python
core-metadata spec) as arrays at all times.
* If METADATA has a body, use it as the description (per spec)
* If Description comes from a header, then strip leading space-pipe text
as per spec.
* Allow the last header (field: value) to end without a newline.
(Using \Z regex)
This allows the parser to process both METADATA and WHEEL files.
* Only use Project-URL as package url if one is given in METADATA
* Set package maintainer based on Maintainer-Email field
Python Environment:
* Move default python detection to a separate method
Also:
* Fix typo in `pip wheel` invocation with wrong variable name
* Remove 'json' require since it's no longer used.
Breaking:
* Removed calls to `setup.py` since this seems deprecated/unusable in
almost any modern python package. [2]
* No longer work: `--python-install-data`, `--python-install-lib`, and
`--python-install-bin`. The reason: `pip install ...` doesn't seem to
support such flags, so there's no way to use these flags. Instead,
you must set `--prefix` if you want to choose where the package
installs if not the default location
New Behavior:
* When --python-bin isn't given to fpm, automatically try to find a
correct python executable name[1]
* When --python-package-name-prefix isn't given, set a default based on
the default --python-bin. That is, if python3 is being used, packages
should default to a name prefix of "python3-"
* Package 'architecture' now will be "all" or "native" depending on the
wheel file's `Root-Is-Purelib` field. It's unclear if this is the correct
way to determine this, though.
Implementation Details:
* Parse package metadata from the wheel (METADATA and WHEEL files)
* Download pypi packages as wheels when available. Previously, fpm would
specify `--no-binary :all:`, but no longer does.
* When source packages are only available, build a wheel locally.
Not yet tested:
* Not yet tested: Package a python module that exists in a local directory
[1] Python is sometimes available as python3, etc.
[2] https://packaging.python.org/en/latest/discussions/setup-py-deprecated/
Jordan Sissel
Jordan Sissel
Alexandr Zarubkin