Skip to content

Exclude .gitignore and .travis.yml from distribution #43

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

Closed
wants to merge 1 commit into from

Conversation

swt2c
Copy link
Contributor

@swt2c swt2c commented Jun 26, 2020

No description provided.

@webknjaz
Copy link
Member

Why? I'd rather remove the manifest altogether because the files are tracked by the setuptools-scm integration.

@swt2c
Copy link
Contributor Author

swt2c commented Jun 27, 2020

Because MANIFEST.in is still the way to exclude files, even when using setuptools_scm. See:
https://pypi.org/project/setuptools-scm/

@webknjaz
Copy link
Member

webknjaz commented Jul 1, 2020

Right, but what's the motivation here? These files are not that big, having them is not harmful.

@swt2c
Copy link
Contributor Author

swt2c commented Jul 1, 2020

Right, but what's the motivation here? These files are not that big, having them is not harmful.

They are harmful, for example, if the source package ends up getting imported to another VCS, e.g., Debian packaging.

@webknjaz
Copy link
Member

webknjaz commented Jul 2, 2020

I guess this is subjective. I don't really see any problem there. Besides, OS package managers usually apply patches anyway and we shouldn't be held responsible for how they solve this.

@swt2c
Copy link
Contributor Author

swt2c commented Jul 2, 2020

I guess this is subjective. I don't really see any problem there. Besides, OS package managers usually apply patches anyway and we shouldn't be held responsible for how they solve this.

So, you want every Linux distribution to have to remove this stuff because you don't want to maintain a 2-line file?

@webknjaz
Copy link
Member

webknjaz commented Jul 2, 2020

Essentially, yes. In fact, this library is not being actively developed.

@swt2c
Copy link
Contributor Author

swt2c commented Jul 2, 2020

Why are you even reviewing my PR then? This is very frustrating for a trivial change.

@webknjaz
Copy link
Member

webknjaz commented Jul 2, 2020

I'm reviewing because nobody else is going to. And also I had a minute + got commit bit recently. So technically I can merge changes that seem reasonable.
Though, I'm not going to invest much time here anyway.

I just wanted to state my position that I only want to care about the dist metadata in the context of publishing to PyPI, hence the Python ecosystem. If each Python project was to support each and every OS packaging case, it'd be a mess and a lot of maintenance burden so this is the policy I apply in the projects I maintain.

If somebody else is going to be responsible for such things, it's different from when I'm being told what to maintain and I opt-out of it.

It doesn't mean that somebody else won't merge this but it's unlikely: Ronny mentioned that he is not going to be maintaining this lib.

Anyway, I've just wanted to say that it's not important/breaking enough for us to care. And fewer things to maintain is better. An example of when it'd be important would be a case with some large unnecessary blob included. But special-casing every each config seems not right.

@swt2c
Copy link
Contributor Author

swt2c commented Jul 3, 2020

Sure, I don't argue that this is a high priority issue. It's just a low priority but trivial thing that should be no maintenance burden and seems to be the right thing to do. Would it make you happy if I deleted the rest of the lines in the file for a net deletion of lines? :-)

BTW, Ronny has commented before that SCM/CI data doesn't belong in sdist: pytest-dev/pytest-xdist#161 (comment)

@webknjaz
Copy link
Member

webknjaz commented Jul 3, 2020

I mean, he said "excludes are sometimes nice" and that such things "don't belong in sdist". And I agree with that, I just wanted to say that even if they are there, they are harmless. So the point of trying to maintain such exclude-lists in an unmaintained project doesn't seem important enough.
You exclude one thing, and then another. And before you know it, you're surrounded by all of these small things you commit to maintaining.
I think that for unmaintained projects, only really dangerous things (like security bugs or stuff that damages env integrity) should be important.

@webknjaz
Copy link
Member

webknjaz commented Jul 3, 2020

FWIW in the very same thread that you linked, Bruno expressed the same sentiment as I do here. And it has lead to removing MANIFEST.in instead of trying to keep it up-to-date.

@swt2c
Copy link
Contributor Author

swt2c commented Jul 7, 2020

Actually, perhaps an even better idea would be for setuptools_scm to exclude these types of files automatically. Perhaps I'll propose that.

@webknjaz
Copy link
Member

Closing per above.

@webknjaz webknjaz closed this Jul 27, 2020
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

Successfully merging this pull request may close these issues.

2 participants