Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Frozen release plans) Progress to 4.0 #89

Open
2 of 13 tasks
cdce8p opened this issue Jan 22, 2021 · 14 comments
Open
2 of 13 tasks

(Frozen release plans) Progress to 4.0 #89

cdce8p opened this issue Jan 22, 2021 · 14 comments

Comments

@cdce8p
Copy link
Contributor

cdce8p commented Jan 22, 2021

This issue should track the progress to the next major release and provide a place to have discussions about features.

Features

Ideas

  • Add support for PEP 639 -> SPDX license tags
  • Update PrettyTable dependency Switch to PrettyTable #82
  • Move from cli only application to cli + lib Calling from within Python #81
  • Add typing + type checking (mypy)
  • Improve CI test -> add environment caching
  • Add ability to specify options in setup.cfg
  • Improve usage for CI license validation -> add some sort of license pinning
  • Add support for importlib.metadata (Python 3.8 and up). Replaces get_installed_distributions
  • Add authors file
  • Add settings files for VS Code
  • Support multiple license files per package

The ideas are subject to change and might not all get implemented. I'll move ideas to the feature column once a PR is created.

Discussions

Add flake8, pylint
Those checks are relatively easy to add and might at some code quality improvements. At least the provide useful guides when used with IDEs (eg. VS Code)

Require Python 3.7
I'm not completely sure about this one. But some good arguments in favor

  • Python 3.6 will be deprecated at the end of the year
  • The switch to 3.7 would allow the use of Data classes and Postponed evaluation of annotations, the last being very helpful (but not required) for type annotations.
  • The move to 4.0 will already be a breaking change, so it would be easy to add it on.
  • Most users will most likely support Python 3.7 and up, given it's already three years old
  • Users that require Python 3.6 can still use the current version which works perfectly fine. They will probably upgrade soon anyway.
@raimon49
Copy link
Owner

raimon49 commented Feb 3, 2021

Note: I have a security alert from dependabot and have updated the dev-requirements.txt . So, dev-4.0.0 has been rebased to commit 7dba43c and force pushed.

@cdce8p
Copy link
Contributor Author

cdce8p commented Feb 3, 2021

Note: I have a security alert from dependabot and have updated the dev-requirements.txt . So, dev-4.0.0 has been rebased to commit 7dba43c and force pushed.

Thanks for letting me know!

@raimon49
Copy link
Owner

I was notified of an insecure version of the dependency from dependabot and the dev-4.0 branch was rebased to 3c9aab1.

@johnthagen
Copy link
Contributor

I'd love if #71 were considered for 4.0 somehow. As someone who relies on pip-licenses to help properly display license information of third party packages, missing some of their license files has always felt a little non-ideal. I'd created a proof-of-concept in #78 on what this could look like.

@cdce8p
Copy link
Contributor Author

cdce8p commented Feb 26, 2021

I'd love if #71 were considered for 4.0 somehow. As someone who relies on pip-licenses to help properly display license information of third party packages, missing some of their license files has always felt a little non-ideal. I'd created a proof-of-concept in #78 on what this could look like.

@johnthagen I unfortunately didn't had much time the last couple of weeks so the progress came to a bit of a hold. Hope to continue with it soon. As for your suggestion, I've added it to the list. It does seem reasonable. Have to see how to best implement it.

@johnthagen
Copy link
Contributor

Have to see how to best implement it.

Sounds great. Feel free to check out #78 where I had a working prototype. The challenge was consistency with output formats that had difficulty handling a list of license files.

I personally only need --format=plain-vertical as I feel its one of the few that works well with license file contents (which can have all kinds of characters that mess up other table-based formats anyway).

@raimon49
Copy link
Owner

dev-4.0 branch has been rebased with v-3.3.1 tag as the branch source.

@cdce8p Can I leave it to you to port the code that corresponds to #94?

@cdce8p
Copy link
Contributor Author

cdce8p commented Feb 28, 2021

@raimon49 Just opened #96

@raimon49
Copy link
Owner

raimon49 commented May 3, 2021

Today, I added the following commit to my master branch.

dev-4.0 branch has also been rebased from the latest master branch. The test cases have priority over the code in the dev-4.0 branch.

@cdce8p
Copy link
Contributor Author

cdce8p commented May 23, 2021

Today, I added the following commit to my master branch.

dev-4.0 branch has also been rebased from the latest master branch. The test cases have priority over the code in the dev-4.0 branch.

Thanks for the heads up. I unfortunately don't have much that free time to work on it at the moment, although I do plan to come back to it at some point.

The last few weeks I've worked on a few improvements for setuptools that will ultimately also help us here once they are widely adopted. That includes

  • Correctly escape the License metadata field. Previously, multiline licenses would almost certainly have broken the metadata file.
  • The license_files option now supports glob patterns, overwrites any manifest settings and has reasonable defaults if not specified. That should help many projects with including their license files in the source distribution. wheel does include something similar for the build distribution.
  • Added support for the License-File metadata field. That should help finding the relevant licensing files in a package. Add License-File field to package metadata pypa/setuptools#2645

@johnthagen
Copy link
Contributor

@cdce8p As more people move to alternatives to setuptools such as Poetry, will these enhancements also need to be added to those tools as well?

@cdce8p
Copy link
Contributor Author

cdce8p commented May 23, 2021

@cdce8p As more people move to alternatives to setuptools such as Poetry, will these enhancements also need to be added to those tools as well?

I believe so, unfortunately. Especially the License-File metadata field probably depends on PEP 639 before it really takes off, but there hasn't been much movement on it lately. https://discuss.python.org/t/pep-639-improving-license-clarity-with-better-package-metadata/2154

@johnthagen If you're familiar with Poetry, maybe you want to open an issue there for them to add it. (Since I haven't used it, I don't know what features regarding license files they do support.)

@raimon49
Copy link
Owner

@cdce8p Thank you for giving us such great news! Your contribution to setuptools is excellent.

@raimon49 raimon49 changed the title Progress to 4.0 (Frozen release plans) Progress to 4.0 Nov 6, 2022
@raimon49
Copy link
Owner

raimon49 commented Nov 6, 2022

pip-licenses 4.0.0 has been released, including some of the plans discussed in this issue.
https://pypi.org/project/pip-licenses/4.0.0/

For this reason, I have changed the issue title.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants