fez has to respect .gitignore

[vrurg]

When I work from macOS over NFS, the system creates dot-under (._) files to keep various meta-data. I got used to these by adding them to .gitignore. Correspondingly, git archive doesn't include them into a tarball created.

Unfortunately, this doesn't work for fez and today I observed the following message:

>>= Looking in "sdist/770gjije.tar.gz" for META6.json
=<< File "raku-Config-BINDish/lib/Config/._BINDish.rakumod" in tar not found in meta<provides>
=<< File "raku-Config-BINDish/lib/Config/BINDish/._Actions.rakumod" in tar not found in meta<provides>
=<< File "raku-Config-BINDish/lib/Config/BINDish/._Grammar.rakumod" in tar not found in meta<provides>
=<< File "raku-Config-BINDish/lib/Config/BINDish/._X.rakumod" in tar not found in meta<provides>
>>= meta<resources> looks OK
>>= Config::BINDish:ver<0.0.16>:auth<zef:vrurg> could use some sprucing up

I checked out content of the tarball in sdist/ and, indeed` it does contain these!

Perhaps it'd be better to either fully respect META6.json content or, my preferable, to let git create the tarball if is being ran under a repository root.

[vrurg]

having git create the tarball created way more issues

I have been thinking about it for a while and, through considering making git archive a configurable option, came to an idea of allowing a user to submit their own tarball. We better remember that git is not the only one and, perhaps, not the ultimate VCS around there. Other systems (and, perhaps, project managers of some kind) is likely to have different ways of specifying valid file names. The only thing which is permanent is the set of files one would like to be distributed and their knowledge of what set is it. So, not guessing it for them is, perhaps, the best solution.

[tony-o]

@vrurg you're able to do this already with fez upload --file=<path to tar gz>

[tony-o]

Git archive isn't available in all versions of git nor in all builds, so relying on it is a bad idea. The other bit that causes a ton of confusion is that git archive creates the tar gz based on what's committed and not what's in the current directory, causing a ton of confusion for users (a lot of bug reports) and documenting doesn't fix. I'll add an option to the glob matcher to behave more similiarly to git's glob matching, currently it works as strictly glob matching (gitignore doesn't).

[vrurg]

I overlooked the --file option and it actually solves my problem.

Considering the problems about git archive, I'd fully agree that adding support for it would cause more problems than it would solve.

With all that in mind, this issue can be closed unless you plan to use as an anchor for extending the functionality of file ignoring.

[tony-o]

I believe this is fixed in v45 and will behave more like gitignore than strict typeglobbing now.

[tony-o]

Would appreciate feedback on whether it's doing as requested @vrurg

[vrurg]

How can I just create an archive without actually uploading it?

[vrurg]

Ok, fez review then. Here we go with AttrX::Mooish sources:

⇒ fez review                                          29-03-23 19:56:30 [v1.0] Earlier failure:
 Malformed UTF-8 near bytes 00 0e b0 at line 1 col 38
  in block  at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/sources/C8881495DA79701F8C813F4864132EE963F6A34B (Fez::Util::FS) line 4
  in sub MAIN at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/sources/F487B4F28B996367E19CD624F0D3C3E7696C4249 (Fez::CLI) line 872
  in sub MAIN at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/sources/F487B4F28B996367E19CD624F0D3C3E7696C4249 (Fez::CLI) line 849
  in sub MAIN at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/sources/F487B4F28B996367E19CD624F0D3C3E7696C4249 (Fez::CLI) line 252
  in block <unit> at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/resources/B866C88FEA9FE3AA035E848A7AAC29615823578C line 4
  in sub MAIN at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/bin/fez line 3
  in block <unit> at /home/vrurg/.rakubrew/versions/moar-2023.02/install/share/perl6/site/bin/fez line 1

.gitignore:

._*
.precomp/
.idea/
AttrX-Mooish-v*
*.iml

find . -name '._*' looks like this:

./._Makefile
./lib/AttrX/Mooish/._ClassHOW.rakumod
./lib/AttrX/Mooish/._Helper.rakumod
./lib/AttrX/Mooish/._ParametricRoleHOW.rakumod
./lib/AttrX/Mooish/._X.rakumod
./lib/AttrX/Mooish/._Attribute.rakumod
./lib/AttrX/._Mooish.rakumod
./lib/AttrX/._Mooish

There are actually more of these meta-files, but this would suffice to give the idea.

[tony-o]

@vrurg where is that repo?

[vrurg]

The link is also in #92 : https://github.com/vrurg/raku-AttrX-Mooish

[tony-o]

ty - will fix before next release.

[vrurg]

BTW, it would not be easy with regard to the unicode error since I, apparently, do not commit the meta-files. :)

But simply not attempting to read what's in .gitignore would already be good enough. Not sure as to what's your intentions about binary files in general.

[tony-o]

It's interesting, I may need to get a USB key to replicate this ._* issue as I can't seem to make my mac create those and adding trying to create those as regular files makes fez respect the .gitignore

[tony-o]

Added the .gitignore to the refresh command, great catch - thanks @vrurg

[vrurg]

I may need to get a USB key to replicate this ._* issue as I can't seem to make my mac create those

I get 'em on an NFS drive. These are unlikely to be the only source of 'badly formatted unicode' problem. It is likely to require more generic solution.

[tony-o]

@vrurg true - i was able to replicate on an NFS share (using smb) and fez did the right thing in regards to .gitignore (and caused no errors after the fix)