You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation states that the first .gitignore file in the project is taken inconsideration when selecting files to include in a wheel/distribution. This leads to unexpected and unwanted behavior. The option to ignore files ignored by version control systems leads to the expectation that no files ignored by git are included in the wheel/distribution. Unfortunately, only some files are excluded.
Rationale
A repository often contain files that should not be included in a public repository or distributions. Personally, I often have a directory with scratchpad/notebook files to do quick tests while developing, and a directory named .secrets with, well, secrets. Since I don't want to include the names of those folders in the main .gitignore file, I add a .gitignore files with the content * in those subdirectories. This makes it much harder to accidentally commit those files to the repository.
So far, so good.
When publishing a package, it is expected to have the same files in the tarball than in the repository; i.e., it should not matter whether you install from GitHub or from a tarball. On first sight, Hatch provides a way to assist in this by adopting the exclusions from .gitignore. A careful inspection of the documentation (or by getting an angry e-mail from PyPI†) one can find out the expectations do not match reality. .gitignore files in subdirectories are ignored (or maybe one is used?).
Proposed improvement
I propose Hatch finds all .gitignore files in the project directory and follows their exclusion.
Alternatively, Hatch could by default only include files that are in the git file listing (if a git repo is present). This would reduce the probability of accidentally publishing files that should have stayed local.
†: Yes, I have since, against my will, moved the PyPI token from the project directory.
The text was updated successfully, but these errors were encountered:
Also, when you e.g. ignore all csv files using *.csv in the main repository's .gitignore file, but do want to include a specific csv file in the src/myproject/resources directory by including a .gitignore in that directory with a negation !demo_data.csv... it is included in the repository but not in the published package. So my app crashed when people were trying it out.
The documentation states that the first
.gitignore
file in the project is taken inconsideration when selecting files to include in a wheel/distribution. This leads to unexpected and unwanted behavior. The option to ignore files ignored by version control systems leads to the expectation that no files ignored by git are included in the wheel/distribution. Unfortunately, only some files are excluded.Rationale
A repository often contain files that should not be included in a public repository or distributions. Personally, I often have a directory with scratchpad/notebook files to do quick tests while developing, and a directory named
.secrets
with, well, secrets. Since I don't want to include the names of those folders in the main.gitignore
file, I add a.gitignore
files with the content*
in those subdirectories. This makes it much harder to accidentally commit those files to the repository.So far, so good.
When publishing a package, it is expected to have the same files in the tarball than in the repository; i.e., it should not matter whether you install from GitHub or from a tarball. On first sight, Hatch provides a way to assist in this by adopting the exclusions from
.gitignore
. A careful inspection of the documentation (or by getting an angry e-mail from PyPI†) one can find out the expectations do not match reality..gitignore
files in subdirectories are ignored (or maybe one is used?).Proposed improvement
I propose Hatch finds all
.gitignore
files in the project directory and follows their exclusion.Alternatively, Hatch could by default only include files that are in the git file listing (if a git repo is present). This would reduce the probability of accidentally publishing files that should have stayed local.
†: Yes, I have since, against my will, moved the PyPI token from the project directory.
The text was updated successfully, but these errors were encountered: