flit: Add option to ignore VCSError

While in development, I want o be able to run flit build before commiting and adding files to my github repo.

if I do that I get

$ flit build
flit.common.VCSError: Untracked or deleted files in the source directory. Commit, undo or ignore these files in your VCS. (.)

I want to be able to do:

$ flit build dev
#or
$ flit build --novcs

So I can test my builds before commiting

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 7
  • Comments: 21 (10 by maintainers)

Most upvoted comments

I understand the flit approach this way:

  • use the index to decide what has to be included in sdist, but build against the working tree.

With respect to this approach we have three different cases

  1. files in the index but missing in the working tree. This is an error, since I’m instructing flit to add to the sdist a non-existing file.

  2. files in the working tree but not in the index. This should be a warning, and those files should not be included in the sdist

  3. files in the working tree modified with respect to the index. This should be a warning, since I’m building (and possibly publishing) a version which is not yet consolidated under VCS.

Currently for flit, 1. and 2. are an error and 3. is ignored.

My suggestion: make 2, and 3 warnings, and add a way for silencing them, something like export FLITVCSUNTRACKED=ignore and export FLITVCSMODIFIED=ignore, on the line of PYTHONWARNINGS

Finally, regarding your suggestion about a scratch directory: I think that it is a bit intrusive from flit to dictate how I should organise my working tree, and where and when I have to put/commit my files. If my VCS hygiene is not up to the flit standard, I would kindly accept a suggestion (i.e. a warning) but the fact that flit refuses to work, without a compelling reason, in my personal setup, is a great annoyance.

But again, this is just my personal view, so thank you for your comments.

There are some cases

  1. I want to assure the build happens without error
  2. I want to test the builded package is installed with no errors
  3. I want to pack the builded package as other packages (.deb or .rpm for example) I use a tool which takes the .tar.gz and repacks it for distribution on other formats, so I want to test it.
  4. I want to ensure the assets are there, static files for example and also assure the description generated by my Markdown to Rst is good.

I know it is not a common case, not everyone tests the builds like this.

By default, the source dist includes everything that’s tracked in your VCS under the folder containing pyproject.toml. So it gives this error because it doesn’t know whether the files should be included in the sdist or not.

Since Flit 2, you can include & exclude files in the config file (https://flit.readthedocs.io/en/latest/pyproject_toml.html#sdist-section ). So you could have a scratch/ subfolder and put it in the exclude list. But you could also add it to .gitignore, which should have the same result.

Maybe I’m a VERY sloppy programmer, but usually I have test files lying in my working tree, that I do not want to add to the index. They are just there for future work, testing, todos, etc. I know how to manage a correct build/test/VCS process: the extra-security that makes impossible to shoot myself in the foot is just annoying.

In other words, what’s the point in forcing me to add to the index a todo.txt file that is in a place that will not be included in the source dist or the python wheel?

(Just my opinion, so please feel free to ignore my comment, If you think that this is an important flit feature.)

I just came across this issue because I’m setting up flit for the first time on my first project. I thought I wanted a bypass flag when I got here, but now I’ve changed my mind.

Perhaps you could avoid the user confusion by using the word “Add” instead of “Commit” in the error message? If the error message hinted that a git add . was all I needed to be able to continue it would have made the lazy thing also the right thing.

I think if Git proves to be too complex for you and you are happy with local SCC, you may want to try Fossil <fossil-scm.org>.

Thanks for the steer Richie - if I was sticking with local SCC, I’d definitely look into Fossil.

The problem isn’t complexity. It’s just that I had a lot of balls in the air trying to understand how python packaging works - especially given that from an outsiders perspective, I’m trying to do this in the middle of a packaging war! Adding learning how VCS or local SCC works and integrates with my IDE did not add to the fun.

In the end I’ve bitten the bullet, read an awful lot of sometimes contradictory documentation, and got github, setuptools, twine and pypi working for me. Quite a lot red wine followed.

I’ll amend my previous comment though: the requirement for VCS in flit isn’t newbie friendly. That said neither is the pypa recommended approach!

While I’d prefer flit for simplicity, I’m going to hold off for now until there is some sort of resolution on #236.