Add option to ignore VCSError

[rochacbruno]

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

[takluyver]

I've deliberately started off with this strict with this to see how it works out before relaxing it. To help me understand the need:

• What kind of files do you have that aren't tracked by the VCS? Are they new code (which should be in the sdist), or odds and ends for testing which you're not going to commit?
• Why are you calling flit build? Do you want to check that it succeeds? Or do you want to use one of the built files? And if so, what do you want to use it for?

The idea is that you need to make a positive decision on which files belong in the sdist. Since I'm trying to avoid something like MANIFEST.in, the VCS is how we decide that. The error message isn't quite accurate: you don't actually need to commit new files, it's enough to git add them (or ignore them).

Depending on what you want this for, you can run flit wheel during development - that doesn't rely on the VCS, so it's not affected by the check.

I want to avoid adding a 'eh, whatever' flag which just bypasses the check, because developers are lazy, and before long people will just use that flag all the time.

[rochacbruno]

maybe add a test mode?

I want to test my builds before commiting and releasing, so flit test-build would be nice.

I see your motivation and I agree, but you can keep the constraints on publish command and allow one to test the build without publishing it.

[takluyver]

I want to test my builds before commiting and releasing

Do you mean you want to test that building works? Or you want to build it so that you can run tests? And if so, how are you doing that?

[rochacbruno]

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.

[Carreau]

Why not commit everything, and test without pushing ? If all works great, than all is good, otherwise just --amend your commit ?

[takluyver]

Reiterating, but you don't actually need to make a commit - just git add any new files which you want to go into the sdist. You can make more changes before committing them, or unstage if you change your mind.

I'm going to spin a background thread on how we could make this easier - in particular, if there's something better to do than making an option to skip the check.

For the check-the-build-works part, one possibility is to add a command like flit check which does all the checks involved in making a build, but doesn't produce a result (or produces one and discards it). So you'd still see a message about untracked files, but it wouldn't prevent the other checks.

[carlbordum]

I think there's just a bit confusion here, because the exception message doesn't make it clear that you just need to stage all files. Maybe replacing "Commit" with "Stage" will help users that run into this in the future?

"Untracked or deleted files in the source directory. Stage, undo or ignore these files in your VCS."

If mercurial has different terminology we can have different messages based on the vcs. Then we could add the helpful but specific git add command to the message to help users even faster.

[richieadler]

I didn't understand the method flit used to find out what files would be part of the package... apparently somebody needs to create a module for Fossil. Until then, I'm out of luck, apparently.

[takluyver]

If you want to have a go at writing that, it shouldn't be much work - depending on how tricky it is to do the required operations with fossil. It needs:

• A way to detect that a directory is a fossil checkout (the equivalent of checking for the .git directory).
• A function to list the files in a given directory which are tracked by fossil.
• A function to list the files added and deleted in a given directory but not updated in fossil.

[richieadler]

You were right, it wasn't much work.
I'm not comfortable with pull requests yet, but I created the following and it worked OK in my system and I propose them for inclusion if you like to have Fossil support added:

• fsl.py to detect fossil and list the files as indicated;
• a modified __init__.py so you can use fsl.py

I'm attaching them in this ZIP file: fsl.zip

[takluyver]

Thanks, I've turned your files into pull request #224.

[BuongiornoTexas]

A brief comment from someone learning python - I'm putting my first package together and I've just hit the brick wall that flit appears to require that package code is in VCS (at least 'flit build' crashes if you try to run it on a package not in VCS). This requirement isn't in the documentation.

This requirement is hard on newcomers - I'm struggling to learn the mechanics of packaging based on assembling and distributing a small package I'm developing locally. I'm happy enough with my local source code control in the short term. So I'm deferring getting to grips with git until I have a proper handle on packaging (avoiding "trying-to-learn-too-many-things-at-once" syndrome).

It would be nice if flit could provide a sand box/testing mode that novices like myself could use for local packages. Particularly so given that all of the pypa examples and tutorials are based on local packages rather than using a VCS.

Could I suggest either updating the document to specify that flit only works on packages in VCS, or request that flits implements support for local, non-VCS packages?

Finally, my apologies - not quite as brief a comment as I planned!

[richieadler]

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>. There is a branch (still unmerged, I think) where there are some additions I created to use flit with Fossil.

[BuongiornoTexas]

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.