this post was submitted on 27 Jan 2025
14 points (100.0% liked)

Python

6684 readers
4 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 2 years ago
MODERATORS
jnovinger@programming.dev
erlingur@programming.dev
norambna@programming.dev
14
Whats in a Python tarball (programming.dev)
submitted 3 weeks ago* (last edited 3 weeks ago) by logging_strict@programming.dev to c/python@programming.dev
5 comments fedilink hide all child comments
 

From helping other projects have run across a fundamental issue which web searches have not given appropriate answers.

What should go in a tarball and what should not?

Is it only the build files, python code, and package data and nothing else?

Should it include tests/ folder?

Should it include development and configuration files?

Have seven published packages which include almost all the files and folders. Including:

.gitignore,

.gitattributes,

.github folder tree,

docs/,

tests/,

Makefile,

all config files,

all tox files,

pre-commit config file

My thinking is that the tarball should have everything needed to maintain the package, but this belief has been challenged. That the tarball is not appropriate for that.

Thoughts?

top 5 comments
sorted by: hot top controversial new old
[–] eager_eagle@lemmy.world 6 points 3 weeks ago

I do the same. The exception is test data, which sometimes is too large to not dominate the sdist size, so I choose to not include it.

[–] furrowsofar@beehaw.org 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

If your talking about a source distribution archive, generally it is the project in the 'distclean' state. This is decribed in GNU documentation. I think for GNU Make. Not sure if the git specific files should technically be included but maybe these days they should. The 'distclean' state is generally the same code as from the VCS tree but with hard to build files pre-built but probably not platform specific files. The 'maintainerclean' state is basically the clean VCS snapshot nothing pre-built.

Edit: The reason to prebuild some not platform specific files is to minimize the tools needed for installing from source.

[–] logging_strict@programming.dev 1 points 2 weeks ago* (last edited 2 weeks ago)

Thank you. Took me awhile to internalize your very generous and detailed advice

target spelling correction: maintainerclean --> maintainer-clean

Here is the docs covering the topic

GNU Make standard targets

Actions taken

  1. In Makefile, separate GNU Make standard targets from other target categories

  2. Rename make coverage --> make check. This would require including tests/ in tarball

  3. Consider creating targets distclean and maintainer-clean

  4. In MANIFEST.in, remove git related files: .gitignore, .github/**/*

  5. Removed config files: codecov.yml, .readthedocs.yml

[–] furrowsofar@beehaw.org 3 points 3 weeks ago* (last edited 3 weeks ago)

By the way. The only files you mentioned I am less sure about are configs. Specifically if these configs are system specific, probaby only examples or templates should be included but the configs should be built by the build process on the target system.

Edit: It should contain tests. Running some equivalent to 'make check' on the target system is pretty standard.

Edit: Not sure what .github folder tree file contains so cannot say.

[–] logging_strict@programming.dev 1 points 2 weeks ago

Thank you everyone who has contributed to this discussion.

My question has been answered. Unless there are additional questions, along the same topic, consider this thread closed.