repo-helper / whey Goto Github PK

Description

Add a command line option to show the versions of whey and Python, similar to what formate has:

https://github.com/python-formate/formate/blob/7d32b286aebd0a09aee4b259a2b7c132be307f76/formate/__main__.py#L44-L63

Seemingly all of the projects built with whey — aside from whey itself, for some reason — omit the entry for *.dist-info/RECORD from the RECORD file. This has been observed on the following packages (links are to Wheelodex.org, which reports the irregularity at the top of the page):

• toctree-plus
• astatine
• sphinx-toolbox
• emoji-strings
• flake8-strftime
• flake8-sphinx-links
• flake8-slots

(I stopped checking at this point, but I think you get the idea.)

Now, while PEP 427 is not 100% clear on whether RECORD needs to be listed in RECORD, my reading is that it does need to be in there, and the fact that the RECORD in whey itself lists RECORD implies that including it is the intended behavior for whey.

Looks like something is wrong with latest whey 0.0.23.
After upgarde to that version I'm not able now build sphinx-toolbox 3.0.0

+ /usr/bin/python3 -sBm build -w --no-isolation
* Getting dependencies for wheel...
* Building wheel...
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/pep517/in_process/_in_process.py", line 363, in <module>
    main()
  File "/usr/lib/python3.8/site-packages/pep517/in_process/_in_process.py", line 345, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/usr/lib/python3.8/site-packages/pep517/in_process/_in_process.py", line 261, in build_wheel
    return _build_backend().build_wheel(wheel_directory, config_settings,
  File "/usr/lib/python3.8/site-packages/whey/__init__.py", line 63, in build_wheel
    with TemporaryPathPlus() as tmpdir, handle_tracebacks(show_traceback, WheyBackendTBHandler):
  File "/usr/lib/python3.8/site-packages/consolekit/tracebacks.py", line 182, in handle_tracebacks
    return cls()()
  File "/usr/lib/python3.8/site-packages/whey/utils.py", line 56, in __init__
    super().__init__(exception)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)

ERROR Backend subprocess exited when trying to invoke build_wheel

I had a pypoject.toml used for flit and trampolim, and it had a dynamic version. Whey found this, and printed out:

dom_toml.parser.BadConfigError: whey only supports 'classifiers', 'requires-python', and 'dependencies' as dynamic fields.

This doesn't tell me what the offender is, it just lists what it does support (I eventually found it was the version listing). It would be more helpful if this message could look more like this:

dom_toml.parser.BadConfigError: whey only supports 'classifiers', 'requires-python', and 'dependencies' as dynamic fields, not 'version'.

(that is, include the offending item in the message)

I'm packaging your module as an rpm package so I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.

• python3 -sBm build -w --no-isolation
• because I'm calling build with --no-isolation I'm using during all processes only locally installed modules
• install .whl file in </install/prefix>
• run pytest with PYTHONPATH pointing to sitearch and sitelib inside </install/prefix>

Here is list of modules installed in build env

Package                       Version
----------------------------- -----------------
alabaster                     0.7.12
apeye                         1.2.0
appdirs                       1.4.4
attrs                         22.1.0
autodocsumm                   0.2.9
Babel                         2.10.2
beautifulsoup4                4.10.0
build                         0.8.0
CacheControl                  0.12.11
charset-normalizer            2.1.0
click                         8.1.2
codespell                     2.1.0
coincidence                   0.6.2
consolekit                    1.4.1
cssutils                      2.5.1
default-values                0.5.1
deprecation                   2.1.0
deprecation-alias             0.3.1
dict2css                      0.3.0
dist-meta                     0.5.0
distro                        1.7.0
docutils                      0.18.1
dom_toml                      0.6.0
domdf-python-tools            3.2.2.post1
editables                     0.3
extras                        1.0.0
fixtures                      4.0.0
gpg                           1.17.1-unknown
handy-archives                0.1.2
html-section                  0.2.0.post1
html5lib                      1.1
idna                          3.3
imagesize                     1.4.1
importlib-metadata            4.12.0
iniconfig                     1.1.1
Jinja2                        3.1.1
libcomps                      0.1.18
lockfile                      0.12.2
MarkupSafe                    2.1.1
mistletoe                     0.8.2
msgpack                       1.0.4
natsort                       8.0.2
packaging                     21.3
pbr                           5.9.0
pep517                        0.12.0
pip                           22.2.1
platformdirs                  2.5.2
pluggy                        1.0.0
py                            1.11.0
Pygments                      2.12.0
PyGObject                     3.42.2
pyparsing                     3.0.9
pypi-json                     0.2.1
pyproject-examples            2022.5.18
pyproject-parser              0.5.0
pytest                        7.1.2
pytest-datadir                1.3.1
pytest-regressions            2.3.1
pytest-timeout                2.1.0
python-dateutil               2.8.2
pytz                          2022.1
PyYAML                        6.0
requests                      2.28.1
rpm                           4.17.0
ruamel.yaml                   0.17.21
ruamel.yaml.clib              0.2.6
seed-intersphinx-mapping      1.0.1
setuptools                    63.4.2
shippinglabel                 1.0.1
six                           1.16.0
snowballstemmer               2.2.0
soupsieve                     2.3.2.post1
Sphinx                        5.1.1
sphinx-autodoc-typehints      1.19.1
sphinx-copybutton             0.5.0
sphinx-debuginfo              0.2.2
sphinx-jinja2-compat          0.1.2
sphinx-prompt                 1.4.0
sphinx-pyproject              0.1.0
sphinx-tabs                   3.4.1
sphinx-toolbox                3.1.2
sphinxcontrib-applehelp       1.0.2.dev20220730
sphinxcontrib-devhelp         1.0.2.dev20220730
sphinxcontrib-htmlhelp        2.0.0
sphinxcontrib-jsmath          1.0.1.dev20220730
sphinxcontrib-qthelp          1.0.3.dev20220730
sphinxcontrib-serializinghtml 1.1.5
sphinxemoji                   0.2.0
tabulate                      0.8.9
testtools                     2.5.0
toctree-plus                  0.6.0
toml                          0.10.2
tomli                         2.0.1
trove-classifiers             2022.7.30
typing_extensions             4.2.0
urllib3                       1.26.9
webencodings                  0.5.1
wheel                         0.37.1
zipp                          3.8.1

Yesterday, pip 21.3 dropped with PEP 660. What's the status of support here?

Description

The sdist at PyPI is missing tests. Please add tests to sdist to make downstream testing easier.

Steps to Reproduce

Download the 0.1.1 sdist from PyPI and unpack it.

Actual result:

Missing tests.

Expected result:

Tests are in sdist.

Reproduces how often:

Easily reproduced

Version

• Operating System: N/A
• Python: N/A
• whey: 0.1.1

Installation source

PyPI

Other Additional Information:

Here in the docs:

In the examples, it says:

[tool.whey]
source_dir = "src/flake8"

This should be source-dir instead of source_dir.

Description

Using src dir makes broken SDists.

Steps to Reproduce

Use the following minimal pyproject.toml:

[tool.whey]
source-dir = "src"

[build-system]
requires = ["whey"]
build-backend = "whey"

[project]
name = "spam"
version = "0.1.0"

And the following "package":

$ mkdir src
$ mkdir src/spam
$ touch src/spam/__init__.py

Actual result:

Running build:

$ pipx run build

Dies when it tries to make the wheel out of the SDist (requires build 0.5+ with pypa/build#304 )

Traceback (most recent call last):
  File "/Users/henryschreiner/.local/pipx/.cache/a7836b47fd2acf2/lib/python3.9/site-packages/pep517/in_process/_in_process.py", line 280, in <module>
    main()
  File "/Users/henryschreiner/.local/pipx/.cache/a7836b47fd2acf2/lib/python3.9/site-packages/pep517/in_process/_in_process.py", line 263, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/Users/henryschreiner/.local/pipx/.cache/a7836b47fd2acf2/lib/python3.9/site-packages/pep517/in_process/_in_process.py", line 204, in build_wheel
    return _build_backend().build_wheel(wheel_directory, config_settings,
  File "/private/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-ohg7b683/lib/python3.9/site-packages/whey/__init__.py", line 57, in build_wheel
    return foreman.build_wheel(build_dir=tmpdir, out_dir=wheel_directory, verbose=True)
  File "/private/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-ohg7b683/lib/python3.9/site-packages/whey/foreman.py", line 145, in build_wheel
    return builder.build()
  File "/private/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-ohg7b683/lib/python3.9/site-packages/whey/builder.py", line 764, in build_wheel
    self.copy_source()
  File "/private/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-ohg7b683/lib/python3.9/site-packages/whey/builder.py", line 185, in copy_source
    for py_file in self.iter_source_files():
  File "/private/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-ohg7b683/lib/python3.9/site-packages/whey/builder.py", line 167, in iter_source_files
    raise FileNotFoundError(f"Package directory '{self.config['package']}' not found.")
FileNotFoundError: Package directory 'spam' not found.

Forcing build to build the wheel from the source directly, and not the SDist, works correctly.

$ pipx run build --sdist --wheel

Expected result:

The SDist should not be broken.

Version

• whey: 0.16

Background

There are a lot of Python package/project management systems (poetry, flit, hatch, and regular setuptools are ones that come to mind quickly). All have their unique qualities and all, more or less, have the same goals.

Enter whey

I just discovered whey. The documentation doesn't really explain how/why whey is different. So I'm left asking myself: Why whey?

Project Goals/Scope

In my experience, it's extremely beneficial to clearly establish the goals/scope of a project. Not only for one's own sanity, but also to help clearly and concretely communicate to others what the project is about. This is especially helpful in open source projects to focus the efforts of contributors and reduce (if not eliminate) superfluous PRs that don't really go in the direction envisioned for the project.

Doing this also helps reduce/prevent scope creep and helps to determine if some feature or functonality should be in the project or should be a sub-project/plugin/etc.

Efficiency / Duplication of Efforts

I like efficiency. I also have a strong distaste for duplicating efforts. (Now that's just me...) I am definitely not going to go rewrite something like numpy or pandas from the ground up. But either (a) improving/adding functionality to the core project or (b) extending the core in some way to add functionality... that's great. Excellent examples of this would be how pint-pandas extends pandas to utilise pint

Differences/Comparison

As a developer, it's not always the most pleasant thing to compare your work or project to others. Yet, others will do it regardless and, at the end of the day, the project lead/originator/inventor is, ultimately, likely the best person to do the comparison (because he/she recognized a need and understands best the differences). There are several examples at the end and I've included a list of questions in a later section.

Humour Is Great (and often based in reality)

The reality, as we know, is that the above XKCD isn't far from the truth... And the very reason why it's funny could be an excellent starting point for a project.

Questions to Consider Answering

Note: @domdfcoding you may have already answered these in your head or maybe not. My suggestion is to write about it so that others can understand. 😀

• What are the goals of whey? What does whey set out to accomplish? What unmet need is whey attempting to solve? What's the scope? (These can always be changed/updated. But having them clearly defined helps to have a baseline so you can decide whether or not to change them.)
• Are there projects that are similar (there are, in this case...)? What do they do? What do they do well? What do they do not so well? What don't they do?
• How does whey compare to these other projects? Features? Capabilities? Goals? Scope? What makes whey different? ... Why (do you think) whey is better?
• What does whey do well? What doesn't whey do so well? (And the latter question can be broken into 2 subparts: What doesn't whey do so well right now [but is planned]? What doesn't whey do so well and isn't in the scope of the project?)
• Roadmap (ties in with scope/goals): Where is whey going? Features? Plans?

As an example, whey's readme indicates

• supports PEP 621 metadata.
• can be used as a PEP 517 build backend.
• creates PEP 427 wheels
• handles type hint files py.typed and *.pyi stubs

Great! So, how do poetry, flit, hatch, and setuptools compare? I don't really know, but I'd like to! 😁

Examples of Answers to some of the above from other projects

• pint's design principles
• python-zstandard State of Project and Comparison
• dbup Philosophy Behind Dbup
• myst-parser Background and explanation
• kopf "vision" and kopf "alternatives"

Description

On encountering an invalid entry, such as recursive-include dhcpd_configurator/templates/*.template, whey will error as it is expecting a space between the path and the file pattern (e.g. recursive-include dhcpd_configurator/templates/ *.template). Currently the error is IndexError: list index out of range. Instead the error should inform the user of the incorrect syntax so they know what to fix,

Version

• whey: 0.0.24

I had some feedback for the PEP 621 guide:

• version doesn't need to be specified or be static in PEP 621; tools often have SCM or file based methods to get it. I think you are thinking about the METADATA record field, which does need it statically defined. I'd clarify that this is currently whey specific.
• One of the lines under version should be under name instead (Ideally, the name should be normalized to lowercase, with underscores replaced by hyphens).
• The inline table form might be nicer for the readme and license? I'd also show the most common readme example, readme = { file="README.md", content-type="text/markdown"}
• I'd point out that the description is the "short" description, or that it's supposed to be short. readme is the long one.
• I think the author example should have at least one with name and email, as that's the most common, I'd expect. Probably the inline form is best, as TOML out-of-line lists are ugly, IMO.

I'd also include a full-sized example at the end or beginning, showing most of the options in a reasonable project.

Nice that there's a tool section too :)