Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

What belongs in the manifest? #1708

Answered by Byron
EliahKagan asked this question in Q&A
Oct 13, 2023 · 1 comments · 4 replies
Discussion options

I've noticed that some top-level files that are often not included in sdist and wheel distributions for PyPI, such as CONTRIBUTING.md, are listed in this project's MANIFEST.in, but that SECURITY.md is omitted. I'm curious if this is intentional and what determines which of these files should be included.

In spite of being top-level in the repository, arguably SECURITY.md is like an issue or PR template, serving to influence how GitHub presents the repository. Even if this is not seen to be its main role, the current SECURITY.md uses the convenient :white_check_mark: and :x: notation that non-GitHub Markdown parsers often don't render even when set to GFM.

A perhaps better reason to omit it is that researchers reporting vulnerabilities are always best informed by whatever the latest guidance in SECURITY.md is, even if that differs from what is written in SECURITY.md in the version of the package they are using. However, this reasoning might also apply to CONTRIBUTING.md. In both cases the matter is mitigated by how probably nobody is ever looking at these files from the PyPI package anyway.

You must be logged in to vote

That's a great question, and one I have no answer for.

I think historically this template was created based on a list of files from the old days without deep thinking, and it hasn't been updated since.

To my mind, it should contain whatever is customary so it matches the average person's expectation, but I don't have preferences myself.

In Rust, I let my crates only contain the source (without tests), the license and a changelog, as all of these affect the usage of the contents of the package, just because this makes sense to me.

Replies: 1 comment · 4 replies

Comment options

That's a great question, and one I have no answer for.

I think historically this template was created based on a list of files from the old days without deep thinking, and it hasn't been updated since.

To my mind, it should contain whatever is customary so it matches the average person's expectation, but I don't have preferences myself.

In Rust, I let my crates only contain the source (without tests), the license and a changelog, as all of these affect the usage of the contents of the package, just because this makes sense to me.

You must be logged in to vote
4 replies
@EliahKagan
Comment options

EliahKagan Oct 14, 2023
Collaborator Author

To my mind, it should contain whatever is customary so it matches the average person's expectation, but I don't have preferences myself.

I'll look into what similarly arranged Python projects that use the setuptools backend and have manifest files are doing with them.

@EliahKagan
Comment options

EliahKagan Oct 20, 2023
Collaborator Author

One thing I've come to wonder about is why the problem in gitpython-developers/gitdb#25 happened for gitdb but not for smmap or GitPython (both of which have MANIFEST.in and neither of which lists it in itself).

@EliahKagan
Comment options

EliahKagan Oct 20, 2023
Collaborator Author

Although this isn't a complete (or really any) explanation, on closer inspection, it looks from the error message like this was due to C code in gitdb that was since moved to gitdb-speedups. (This was also a long time ago, using Python 2.)

All the C-related stuff in gitdb's MANIFEST.in could probably be removed at this point and, at the same time, I think MANIFEST.in could be removed from itself too. But I'm not in a rush to do that, because maybe even more could should be removed from it, or maybe the file could be eliminated altogether.

@EliahKagan
Comment options

EliahKagan Nov 4, 2023
Collaborator Author

Relating to #1716 (comment), I think the question of what belongs in MANIFEST.in can (and may need to) be revisited when making the project definitions declarative. I don't think I'll feel a need to propose changes to it, in any of the three projects, before that, so I'm closing this. However, this is not with the intention of preventing anyone else who is interested in making improvements sooner from doing so!

Answer selected by EliahKagan
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.