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

Please include composer.json and phpunit.xml.dist in release archives #47

Closed
merkys opened this issue Aug 30, 2019 · 7 comments · Fixed by #52
Closed

Please include composer.json and phpunit.xml.dist in release archives #47

merkys opened this issue Aug 30, 2019 · 7 comments · Fixed by #52

Comments

@merkys
Copy link

merkys commented Aug 30, 2019

Inclusion of composer.json and phpunit.xml.dist would greatly simplify testing of downloaded source release archives prior to using them. Moreover, composer.json contains a lot of metadata (machine-readable dependency list), which I think is worthy to have together with the source.

JeroenDeDauw added a commit that referenced this issue Aug 30, 2019
@JeroenDeDauw
Copy link
Member

Why not just download the code via git? composer.josn and phpunit.xml.dist are only removed if a git export is done. If you are using composer to get the code you can pass the --prefer-source flag.

@merkys
Copy link
Author

merkys commented Sep 4, 2019

I am interested in packaging DataValues for Debian (as a prerequisite for Wikibase), and having stable HTTP(S) URIs for testable release archives would be very helpful, although I can in principle get around with git. However, release archives contain test files, but not the metadata required to execute the tests offline – why not include it?

@JeroenDeDauw
Copy link
Member

That is rather weird yes. Just the case for the latest releases though, on master the test directory is also excluded since 9b54bf3

My first reaction to exclusion of tests is that it removes potentially useful info, since tests have a documenting function. And while I still think that, there are a number of Wikiemdia people that want these things excluded. If it was just them... but many open source projects are doing the same, so there presumably is some kind of non-Wikimedia motivation as well?

So I'm undecided on what to do with this

@JeroenDeDauw
Copy link
Member

Btw I will make a new release tomorrow so this is consistent

JeroenDeDauw added a commit that referenced this issue Sep 5, 2019
Fixes #47

If the tests need to be included anyway (as per #50)
then also having this config is not going to make much of a difference.
AlaaSarhan pushed a commit that referenced this issue Sep 5, 2019
Fixes #47

If the tests need to be included anyway (as per #50)
then also having this config is not going to make much of a difference.
@manicki
Copy link
Contributor

manicki commented Sep 9, 2019

For what it's worth, the motivation for excluding certain files via .gitattibutes, when that originally happened was Wikimedia one. Namely, it was a means to not include not needed files in Wikimedia's Mediawiki Vendor component.
That said, exclude files from the git export is not the only way to achieve e.g. not included not wanted files, tests etc from the said component, e.g. for libraries beyond Wikimedia's control, git-ignoring in the component itself has been used, see https://github.com/wikimedia/mediawiki-vendor/blob/3ff8ee3dd4ac225dce030b400b3ad0f75bb5ed7e/.gitignore#L39.

I'd personally say that ignoring in this "MW vendor" thing is a better approach, as the library author should define themselves what they are willing to export.

Whether the above information should determine any changes to the DataValues libraries, I have no opinion.

@merkys
Copy link
Author

merkys commented Sep 13, 2019

Coming from outside the MW, for me it is a bit difficult to understand the reasons for exclusion of this data from releases. It's always easier to delete unneeded data than to find the ways to get it. But for sure things should be done in convenience for primary users.

Thanks a lot for including these files in the release!

@JeroenDeDauw
Copy link
Member

We still need to release that as 2.3 though...

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