pypa / flit Goto Github PK

The requires field should be a valid requirements.txt file, so we can shell out to pip to install these.

Suggestion from @minrk

In flit default, make "home_page_template" a list.
Propose each.
if user type something complex -> assume it's what is ment.
otherwise if it parses to an int, select that from the list.

License, same principle with Non-shown licence. Typing BSD, GPL should match.

I already do that here:

https://github.com/Carreau/PipCreate/blob/master/pipcreate/pipcreate.py#L66-L78

Might need a (weekly) cache for speed ?

Narrowed down to test_wheel, in particular the following:

def test_entry_points_conflict():
    clear_samples_dist()
    with pytest.raises(EntryPointsConflict):
        wheel_main(samples_dir / 'entrypoints_conflict.ini')

If one record warnings:

py.test -p recwarn tests/test_wheel.py
=================================================================== test session starts ===================================================================
platform darwin -- Python 3.5.2, pytest-3.0.4.dev, py-1.4.31, pluggy-0.4.0
rootdir: /Users/bussonniermatthias/dev/flit, inifile:
plugins: warningsfilters-0.0.1, xonsh-0.4.6
collected 1 items

tests/test_wheel.py .

=== 1 passed in 0.13 seconds  ===
Exception ignored in: <bound method ZipFile.__del__ of <zipfile.ZipFile [closed]>>
Traceback (most recent call last):
  File "/Users/bussonniermatthias/anaconda/lib/python3.5/zipfile.py", line 1595, in __del__
    self.close()
  File "/Users/bussonniermatthias/anaconda/lib/python3.5/zipfile.py", line 1607, in close
    self.fp.seek(self.start_dir)
ValueError: seek of closed file

You were involved in the zipfile patch, so pinging you first. I'm gonna assume a self._fpclose(self.fp) is called without setting self.fp to None.

I don't see where except maybe zef_file.close()...

Based on the version number ?

0.0.x -> alpha
0.X.y -> Beta
X.y.z -> Stable

take care of devX suffixes ?

Alternatively to set values :-) By reflex I've set author to Matthias Bussonnier <[email protected]>.
and stugled (a bit) to fix it.

Flit currently implements metadata 1.2. It should probably consider upgrading to metadata 2.0. I'm not 100% sure what's involved, or what the downsides are, if any. But since the wheel package has been generating metadata 2.0 for a few years now, roughly all wheels probably use md 2.0, so it seems appropriate / safe.

If ~/.pypirc is not found, or doesn't contain a [pypi] section, it falls back to prompting for a username and password. This could be better:

• Explain what username&password it's asking for, and where to register if you don't already have a login.
• Store the details to ~/.pypirc so that the user only needs to be prompted once
  • But the user may prefer not to store their password in a plaintext file in their home directory, so there should be a way to make it prompt every time.
• If ~/.pypirc exists and there are other server sections, allow the user to pick one of these rather than ignoring it completely.
  • Maybe give a hint on changing .pypirc - on my old computer, it had PyPI under a different section name.

Also, if the user explicitly specifies --repository foo, and there isn't a [foo] section in .pypirc, they will just get a KeyError. This could be more informative.

That lint flit.ini files (for unknown field ?) and potentially report error in "classical" sprintf format which is easy to hook into editors.

Thoughts ?

Can I force flit to reinstall a package without bumping it's version number? I just wanted to do this for development purposes.

Edit: After submitting this I realized I could do this by appending "-dev" to the version, making it non-canonical.

I've been asked a few times to provide setup.py files and/or sdists for projects packaged with flit. This is a central place to think about problems and potential solutions. It is not a commitment to add any particular support for this in flit.

The problems that have been encountered are:

• People want to pip install directly from a Github URL, which only works if the repository contains a setup.py at the top level.
• People using legacy tools such as buildout may be unable to install wheels (see e.g. pexpect/ptyprocess#31).
• Linux distro packagers have toolchains that expect a source tarball with a setup.py file (e.g. jupyter/testpath#6). I don't have much sympathy with this issue, because I think declarative metadata and standard formats will ultimately make repackaging easier.

Potential solutions to some of these problems:

• flituptools is a module which reads metadata from a flit config file and invokes setuptools with it. The idea is that you can check in a setup.py that just calls flituptools.setup(), and either copy flituptools into your repo, or tell users they need it to pip install directly from Github. However:
  • Packages are only installable with flit already installed, and consequently with Python 3.
  • Eeuw, setuptools.
• make_sdist.py is a script I wrote for ptyprocess, to generate a basic sdist from flit metadata. The sdist does not depend on flit, so it can be installed in any version of Python. However:
  • No setup.py in the repo, so it doesn't allow pip install directly from Github. If you do generate a setup.py and check it in, you have duplicate information to keep up to date.
  • People ask for things like tests and docs in sdists, so before you know it, you're reinventing MANIFEST.in, which really doesn't appeal.
  • Technically Linux distro packagers shouldn't use the sdists, as setup.py is generated rather than a source file. In reality, most probably won't notice or won't care.
• @njsmith proposed a new sdist format which would have used a declarative config file to specify the buildsystem to use to make wheels. However:
  • The proposal got mired in different opinions on what it was trying to achieve, and didn't go anywhere.
  • It presumably wouldn't help people with legacy tools, though at least a new standard would provide a better argument for moving to newer tools.
• One could write a setup.py that implements the necessary command line interface for pip (documented here) without calling into distutils/setuptools (thanks @njsmith for the suggestion). Apparently other projects have done this. However:
  • The pip specification basically says "do what setuptools does" - specifically the egg_info command, which creates metadata in setuptools' non-standard format.
    • Perhaps a PR could be made against pip to try bdist_wheel first, and not bother with egg_info if it succeeds? That would make it easier to integrate.

like I mistype requires often.
Would be nice to have a did you mean.

Seem like both --upload and --verify take a repo_name as argument which is the same args,

Seems little bit weird as flit wheel --upload foobar --verify qux does not make sens.

I would add a --pypi or --repo flag, with default that can be read from config.

Could we have a package that does just flit wheel, and has no dependencies? That would make bootstrapping a bit easier.

Furthermore, what would it take to add Python 2 support for such a package?

It has gotten a bit messy now when one wants to install jupyter fully from source, since the new dependency testpath is a Flit package (although if I recall there was another one as well). While the wheel produced is a universal wheel and so it can be used with Python 2 it messes with our build chain and I'm pretty sure other distributions will experience similar issues. We can package wheels, but prefer not to (although the recent choice of setuptools to stop vendoring dependencies forces us in that direction).

It is apparently deprecated when uploading to warehouse:

$ flit register
Using repository at https://upload.pypi.io/legacy/                                                                                   I-flit.upload
Starting new HTTPS connection (1): upload.pypi.io                                                       I-requests.packages.urllib3.connectionpool
Traceback (most recent call last):
  File "/Users/bussonniermatthias/.local/bin/flit", line 4, in <module>
    main()
  File "/Users/bussonniermatthias/.local/lib/python3.5/site-packages/flit/__init__.py", line 104, in main
    register(meta, args.repository)
  File "/Users/bussonniermatthias/.local/lib/python3.5/site-packages/flit/upload.py", line 145, in register
    resp.raise_for_status()
  File "/Users/bussonniermatthias/anaconda/lib/python3.5/site-packages/requests/models.py", line 837, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 410 Client Error: This API is no longer supported, instead simply upload the file. for url: https://upload.pypi.io/legacy/

You seem to miss one :-) [nor speaking of template files :-)]

The python bindings for opencv are created via apt-get install python-opencv, and so I'm guessing flit can't find them. cv2 is installed and works with python.

Is there a way to still build my package without digging into flit and making exceptions for this package? Maybe there is a way to add include it in the paths that flit checks?

$ flit wheel --upload
installing system dependencies
Traceback (most recent call last):
  File "/usr/local/bin/flit", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.4/dist-packages/flit/__init__.py", line 88, in main
    repo=args.repository)
  File "/usr/local/lib/python3.4/dist-packages/flit/wheel.py", line 197, in wheel_main
    wb = WheelBuilder(ini_path, fp)
  File "/usr/local/lib/python3.4/dist-packages/flit/wheel.py", line 44, in __init__
    self.metadata = common.make_metadata(self.module, self.ini_info)
  File "/usr/local/lib/python3.4/dist-packages/flit/common.py", line 228, in make_metadata
    md_dict.update(get_info_from_module(module))
  File "/usr/local/lib/python3.4/dist-packages/flit/common.py", line 78, in get_info_from_module
    m = sl.load_module()
  File "<frozen importlib._bootstrap>", line 539, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1614, in load_module
  File "<frozen importlib._bootstrap>", line 596, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 1220, in load
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "<frozen importlib._bootstrap>", line 1471, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "RPiViz/__init__.py", line 5, in <module>
    from RPiViz import deps, do_magic, executor, identify
  File "RPiViz/do_magic.py", line 2, in <module>
    import cv2
ImportError: No module named 'cv2'

Cheers

There is strong assumption about version string now. If the package is installed, the RequirementParseError: Missing distribution spec error is thrown. Wouldn't it make sense to allow all possible version definitions and just issue a warning is it does not match python spec

A bad groupname can prevent other packages from starting as pkg_resources can raise raise ValueError("Invalid group name", group)

I found some packages on pypi with empty description strings generated by flit. I see a description-file. Does that get translated to a description string ?

It should be possible to quickly walk the AST, get imports and warn if a required package is not imported anywhere.

We can of course get false positive, like scikit-* which imports as sk*, or optional dependencies of subpackages.

We can also likely do the reverse, and warn on things that have not been added to the requires in flit.ini, though we need to get a list of all Python's built-ins modules,which I'm not sure how to get (except by importing and checking the path from import)

We can even be smarter and detect conditional/delayed import and not warn on theses.

It seems like flit would be better off not handling uploading. I think it'd be better to just have it output the wheels and then instruct people to use twine (eventually will become pip upload or pip publish or something) to handle the uploads to PyPI. It seems silly to have a build system handle uploads, especially in a future when there can be multiple different build tools.

The hashes in a wheel's RECORD file are supposed to be in urlsafe base64, with trailing = removed, while flit is writing them in hex. Thanks to @sophacles for pointing this out.

• flit pkg install doesn't create executable wrappers for scripts on Windows
• Flit packages installed with pip also don't get the .exe command line wrappers, because they're not specified through setuptools entry points. I definitely don't want my scripts to use load_entry_point, so I'll try to get that fixed in pip itself.

This might duplicate #74, but there is a lot of information there, so I thought I'd express this issue here.

tox depends upon a setup.py file to manage. We can avoid processing setup.py, but this negates the purpose of the tool -- to install the software from within a container.

$ cat tox.ini
[testenv]
deps = pytest
commands = py.test --verbose {toxinidir}/tests

$ tox
Traceback (most recent call last):
  File "/usr/local/bin/tox", line 9, in <module>
    load_entry_point('tox==2.3.1', 'console_scripts', 'tox')()
  File "/Library/Python/2.7/site-packages/tox-2.3.1-py2.7.egg/tox/session.py", line 39, in main
    retcode = Session(config).runcommand()
  File "/Library/Python/2.7/site-packages/tox-2.3.1-py2.7.egg/tox/session.py", line 375, in runcommand
    return self.subcommand_test()
  File "/Library/Python/2.7/site-packages/tox-2.3.1-py2.7.egg/tox/session.py", line 520, in subcommand_test
    path = self.get_installpkg_path()
  File "/Library/Python/2.7/site-packages/tox-2.3.1-py2.7.egg/tox/session.py", line 496, in get_installpkg_path
    path = self._makesdist()
  File "/Library/Python/2.7/site-packages/tox-2.3.1-py2.7.egg/tox/session.py", line 390, in _makesdist
    raise tox.exception.MissingFile(setup)
tox.MissingFile: MissingFile: /Users/jquast/Code/ptyprocess/setup.py

We can modify tox.ini to ignore using setup.py,

[tox]
skipsdist=true

[testenv]
deps=pytest
commands = py.test --verbose {toxinidir}/tests

But not we're only creating a virtualenv to contain py.test and nothing more. We are using tests from, and testing against the source folder. We aim to test the installed version of our software to verify correct packaging (especially file inclusions/exclusions).

Try 3, to explicitly install dependency flit so that we can install our package for testing:

[tox]
skipsdist=true

[testenv]
deps=pytest
     flit
commands = flit
           flit -f {toxinidir}/flit.ini install
           py.test --verbose {toxinidir}/tests

This fails because flit is only made available as a python 3 wheel and without source distribution, so it fails to install for python2.7 testing. I'm not sure where to go from here.

Traceback (most recent call last):
  File "~/anaconda3/envs/dev/bin/flit", line 11, in <module>
    sys.exit(main())
  File "~/anaconda3/envs/dev/lib/python3.5/site-packages/flit/__init__.py", line 88, in main
    repo=args.repository)
  File "~/anaconda3/envs/dev/lib/python3.5/site-packages/flit/wheel.py", line 210, in wheel_main
    do_upload(wheel_path, wb.metadata, repo)
  File "~/anaconda3/envs/dev/lib/python3.5/site-packages/flit/upload.py", line 164, in do_upload
    upload_wheel(file, metadata, repo)
  File "~/anaconda3/envs/dev/lib/python3.5/site-packages/flit/upload.py", line 133, in upload_wheel
    resp.raise_for_status()
  File "~/anaconda3/envs/dev/lib/python3.5/site-packages/requests/models.py", line 909, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: home_page: Invalid URI for url: https://upload.pypi.io/legacy/

This was fixed by changing

home-page:michaelpacer.com

to

home-page:https://michaelpacer.com

when (on its own…as of the time of this writing https://michaelpacer.com doesn't even resolve correctly because of some DNS issues), which makes me think that this is being caught by pypi's metadata parser as opposed to an actual call to the site. That makes me think it might be possible to catch these errors by mimicking that parsing mechanism. Otherwise, catching the error as a 400 response from https://upload.pypi.io/legacy isn't too informative as to what needs to be fixed.

The 3 licenses to choose from (MIT/GPL/Apache) are mostly incompatible. And will it be GPL v2 or v3?

Most users won't understand the importance of the choice, so explaining in one sentence per license what the consequence is would be very helpful. Something like:

MIT: code be used in projects using BSD, GPL or Apache
GPL: code cannot be used in projects using BSD, MIT or Apache
Apache: code cannot be used in projects using BSD, MIT or GPL

And Apache is a very much undesired license. Given that pretty much the whole system is MIT/BSD/GPL, including it in this menu of choices is unfortunate. Please consider removing it.

If you symlink a directory into site-packages and then pip uninstall, you'll delete all the files in there. If you pip install over it, you'll rewrite the files in it.

I got some improvements into the stdlib and backported them as zipfile36. This should remove the need for a copy of the ZipFile.write() method inside flit.

I quite like toml, and I'm considering switching flit to use it for config files. It's a bit more verbose than ini, because string values have to be quoted, but there's a detailed specification, and it's quite a bit more flexible. We'd gain the ability to have lists (rather than just multiline strings), dates and arbitrarily nested dictionaries, rather than the strict two-level hierarchy we have with ini.

If I did this, I would still support ini files for backwards compatibility for quite some time. It would look for flit.toml first, and fall back to flit.ini if that wasn't found. When supplying the filename explicitly, it would try to parse it as toml if the extension was .toml, and as ini otherwise.

I more and more find myself as wanting the same description from the readme.md/description.md and the __doc__ of my main module.

Would you have any objection to an alternative to description-file that would get the description from the module __doc__.

I (of course) could globals()['__doc__'] = open('../readme.md').read() but that seem ugly.

Thoughts ?

Packages without a sdist are, in my opinion, a bad idea in general. They cannot be packaged by downstream redistributors like Debian, Ubuntu, Fedora, etc because all of those have a policy of only accepting source distributions and Wheels are a binary format. Currently using flit essentially means that that particular package cannot be packaged in a downstream package repository and all of the things that depend on that particular package can also not be packaged in those downstream repositories.

In that vein, flit should produce working sdists and enable uploading them to PyPI.

Of course PyPI does not do it, but if it can't compile the rst description, it throw the raw-text in it's place.

(mistake in one of my package with code-block without a blank line)

I have few hope to have it fixed in PyPI, would be nice fro flit to maybe emit a warning...

As far as I can tell it should be possible to reproduce byte for byte a wheel, is we sort the os.walkdir files and pass the right options to zipfile.

Which is weird, but

Symlinking flit -> /Users/bussonniermatthias/Library/Python/3.5/lib/python/site-packages/flit  I-flit.install
Traceback (most recent call last):
  File "/usr/local/bin/flit", line 11, in <module>
    sys.exit(main())
  File "/usr/local/Cellar/python3/HEAD/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/flit/__init__.py", line 191, in main
    Installer(pkg, symlink=args.symlink).install()
  File "/usr/local/Cellar/python3/HEAD/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/flit/install.py", line 97, in install
    os.symlink(str(self.module.path.resolve()), dst)
FileNotFoundError: [Errno 2] No such file or directory: '/Users/bussonniermatthias/dev/flit/flit' -> '/Users/bussonniermatthias/Library/Python/3.5/lib/python/site-packages/flit'

But that might be because I'm on 3.5a1

I'm trying to decide how best to specify entry points for a package. I've come up with three possibilities, all of which have a drawback.

1. Look for a file called entry_points.txt next to flit.ini and use it if it exists. Downside is that I'm not entirely happy about using a file without being explicitly asked to, and without a way to point it to a different file.
2. Add a field to flit.ini to specify the location of the entry points file. Downside is that in most cases, it's fixed, meaningless boilerplate.
   2a. Like 2, but default to 1 if none is specified. Nicer in some ways, but I feel it's even more strange to use a file without being asked to when there is a way to ask us.
3. Include the extra entry points within flit.ini. I can't think of any neat way of expressing them in INI config, though, and I'm not wild on changing the format just for that.

Ping @Carreau - any preferences, or better still, any amazing option that I've missed altogether?

Cannot this be inferred from the .ini file ?

Does it make sens to ignore hidden files ? like backup file, or swap files ?

(or at least warn that some have been found)

I guess this is a PyPI bug, but we should check for it, that version match pep 440, though I don't findknow where we can find a pep 440 version parser.

with __version__ = '0.0.4-dev0': got requests.exceptions.HTTPError: 400 Client Error: Binary wheel for an unsupported platform

$ flit wheel --upload
Created dist/SPQR-0.0.4-dev0-py3-none-any.whl                                                                                                           I-flit.wheel
Using repository at https://pypi.python.org/pypi                                                                                                       I-flit.upload
Uploading dist/SPQR-0.0.4-dev0-py3-none-any.whl...                                                                                                     I-flit.upload
Starting new HTTPS connection (1): pypi.python.org                                                                        I-requests.packages.urllib3.connectionpool
Traceback (most recent call last):
  File "/Users/bussonniermatthias/Library/Python/3.4/bin/flit", line 4, in <module>
    main()
  File "/Users/bussonniermatthias/Library/Python/3.4/lib/python/site-packages/flit/__init__.py", line 67, in main
    repo=args.repository).build()
  File "/Users/bussonniermatthias/Library/Python/3.4/lib/python/site-packages/flit/wheel.py", line 152, in build
    self.post_build()
  File "/Users/bussonniermatthias/Library/Python/3.4/lib/python/site-packages/flit/wheel.py", line 144, in post_build
    do_upload(self.wheel_file, self.metadata, self.repo)
  File "/Users/bussonniermatthias/Library/Python/3.4/lib/python/site-packages/flit/upload.py", line 164, in do_upload
    upload_wheel(file, metadata, repo)
  File "/Users/bussonniermatthias/Library/Python/3.4/lib/python/site-packages/flit/upload.py", line 133, in upload_wheel
    resp.raise_for_status()
  File "/usr/local/lib/python3.4/site-packages/requests/models.py", line 851, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Binary wheel for an unsupported platform

Because you cannon pip install -e . :-)

Traceback (most recent call last):
  File "/Users/bussonniermatthias/.local/bin/flit", line 4, in <module>
    main()
  File "/Users/bussonniermatthias/.local/lib/python3.5/site-packages/flit/__init__.py", line 88, in main
    repo=args.repository)
  File "/Users/bussonniermatthias/.local/lib/python3.5/site-packages/flit/wheel.py", line 191, in wheel_main
    do_upload(wheel_path, wb.metadata, repo)
  File "/Users/bussonniermatthias/.local/lib/python3.5/site-packages/flit/upload.py", line 164, in do_upload
    upload_wheel(file, metadata, repo)
  File "/Users/bussonniermatthias/.local/lib/python3.5/site-packages/flit/upload.py", line 133, in upload_wheel
    resp.raise_for_status()
  File "/Users/bussonniermatthias/anaconda/lib/python3.5/site-packages/requests/models.py", line 837, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: requires_python: Invalid specifier in requirement. for url: https://upload.pypi.io/legacy/

See https://github.com/Carreau/warn/blob/8fbb2e0a4e8c46f88361ae3d690784444cc8ca5c/flit.ini and previous commit (uploading through warehouse)

I should likely check whether it's a warehouse thing but I want to make sure to fix flit docs if it's not the case.

Is this on purpose ?

$ flit wheel --upload
Created dist/morning-0.1.0-py2.py3-none-any.whl                     I-flit.wheel
Created dist/morning-0.1.0-py2.py3-none-any.whl
Using repository at https://pypi.python.org/pypi                   I-flit.upload
Using repository at https://pypi.python.org/pypi
Uploading dist/morning-0.1.0-py2.py3-none-any.whl...               I-flit.upload
Uploading dist/morning-0.1.0-py2.py3-none-any.whl...
Starting new HTTPS connection (1): pypi.python.org  I-requests.packages.urllib3.connectionpool
Starting new HTTPS connection (1): pypi.python.org

I'm getting an error (flit installed from pip3) on flit's install with:

$ flit install
Installing requirements                                                                                                 I-flit.install
Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/commands/install.py", line 262, in run
    for req in parse_requirements(filename, finder=finder, options=options, session=session):
  File "/usr/lib/python3/dist-packages/pip/req.py", line 1632, in parse_requirements
    req = InstallRequirement.from_line(line, comes_from, prereleases=getattr(options, "pre", None))
  File "/usr/lib/python3/dist-packages/pip/req.py", line 173, in from_line
    return cls(req, comes_from, url=url, prereleases=prereleases)
  File "/usr/lib/python3/dist-packages/pip/req.py", line 71, in __init__
    req = pkg_resources.Requirement.parse(req)
  File "/usr/share/python-wheels/setuptools-3.3-py2.py3-none-any.whl/pkg_resources.py", line 2667, in parse
    reqs = list(parse_requirements(s))
  File "/usr/share/python-wheels/setuptools-3.3-py2.py3-none-any.whl/pkg_resources.py", line 2605, in parse_requirements
    line, p, specs = scan_list(VERSION,LINE_END,line,p,(1,2),"version spec")
  File "/usr/share/python-wheels/setuptools-3.3-py2.py3-none-any.whl/pkg_resources.py", line 2583, in scan_list
    "Expected ',' or end-of-list in",line,"at",line[p:]
ValueError: ("Expected ',' or end-of-list in", 'pexpect>=3.3;', 'at', ';')

Storing debug log for failure in /home/dblank/.pip/pip.log
Traceback (most recent call last):
  File "/usr/local/bin/flit", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.4/dist-packages/flit/__init__.py", line 75, in main
    Installer(args.ini_file, user=args.user, symlink=args.symlink, deps=args.deps).install()
  File "/usr/local/lib/python3.4/dist-packages/flit/install.py", line 176, in install
    self.install_requirements()
  File "/usr/local/lib/python3.4/dist-packages/flit/install.py", line 158, in install_requirements
    check_call(cmd)
  File "/usr/lib/python3.4/subprocess.py", line 557, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'pip', 'install', '--user', '-r', '/tmp/tmpr1zrx823requirements.txt']' returned non-zero exit status 2

• Based on py minimum requirement,
• Ask durign flit-init ?

The other day I tried to 'wheel unpack' a flit wheel, and it had what is probably a trivial metadata but that prevented it from verifying.

https://mail.python.org/pipermail/distutils-sig/2016-June/029083.html

Thoughts ?

When using flit init you are prompted for a license. This is used to set the "Classifiers" field in flit.ini. From what I've seen, many packages fill in both the classifiers and the license metadata field (even though "License" is documented as optional).

Would it be worth using the license choice to populate both Classifiers and License in flit.ini?