Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: validate the source directory passed to ProjectBuilder #260

Merged
merged 7 commits into from
Mar 19, 2021

Conversation

pfmoore
Copy link
Member

@pfmoore pfmoore commented Mar 18, 2021

No description provided.

@pfmoore
Copy link
Member Author

pfmoore commented Mar 18, 2021

Fixes #259.

Initial version, for some reason the tox -e fix command doesn't work on my PC (it doesn't recognise my copy of Visual Studio when building the pre-commit environments) so I can't run the linting locally. I'll let CI do it for me...

@pfmoore
Copy link
Member Author

pfmoore commented Mar 18, 2021

I don't know why the tests are failing, they work locally.

Copy link
Member

@FFY00 FFY00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think checking for either pyproject.toml or setup.py is fine, even though I don't like that people with a setup.cfg will continue with the current behavior, making things slightly inconsistent, so I am not gonna block this.

Comment on lines 66 to 67
pyproject_toml = os.path.join(srcdir, "pyproject.toml")
setup_py = os.path.join(srcdir, "setup.py")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are not running pre-commit. Please use single quotes here 😛

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Is the right way to run pre-commit to use the tox -e fix command? As I said, that's failing for me :-( Is there a contributing guide that explains how to set up for development, run tests, etc? I wasn't able to find one.

I tried running it by hand, which seems to have worked. So I've pushed a fix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should, I don't know exactly what went wrong in your case 😕. Perhaps @gaborbernat might have more insight?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have a contributor guide, but right now I'm ETIME.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, I completely understand.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Is the right way to run pre-commit to use the tox -e fix command? As I said, that's failing for me

Can you provide more exact details for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to later, but basically it said I didn't have Visual C version 14 installed (I have VS 2019) when building the virtualenvs. But when I ran pre-commit outside of tox, it worked, and now tox -e fix works.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird. Was it trying to build some c-extension package (such as black?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I can't recall which one, I'll let you know once I manage to reproduce the issue.

src/build/__init__.py Outdated Show resolved Hide resolved
@FFY00
Copy link
Member

FFY00 commented Mar 18, 2021

You seem to have found an issue with our integration tests 😅. We test building a few popular projects in the CI as a sanity check and it looks like we are invoking build in the directory where the github tarballs are extracted, not the folder that is inside them and contains the project.

I will open a separate PR, you can then rebase on top of it.

@FFY00
Copy link
Member

FFY00 commented Mar 18, 2021

Btw, as the integration tests take a long time and are only included as a sanity check, you need to pass --only-integration or --run-integration to pytest. You can do this in tox as tox -e py39 -- --only-integration.

Sorry for the trouble!

@gaborbernat
Copy link
Contributor

I don't know why the tests are failing, they work locally.

This is why I'm not the biggest fan of not running integration tests locally by default 😆 People think if it passed locally they are done.

Copy link
Contributor

@gaborbernat gaborbernat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic looks ok, but we need tests for these cases.

@pfmoore
Copy link
Member Author

pfmoore commented Mar 18, 2021

Yep, once the current tests pass I'll add tests for the new functionality.

@FFY00
Copy link
Member

FFY00 commented Mar 18, 2021

The tests should now be fixed now, @pfmoore can you rebase your branch on main?

@pfmoore
Copy link
Member Author

pfmoore commented Mar 18, 2021

Thanks for the quick fix, rebase done.

@FFY00
Copy link
Member

FFY00 commented Mar 18, 2021

Thanks, when you come back to add the tests, could you also add an entry in the changelog?

@pfmoore
Copy link
Member Author

pfmoore commented Mar 18, 2021

Done.

By the way, the symlink from docs/changelog.rst to CHANGELOG.rst doesn't get extracted properly on Windows, and messes up the git repo. Twice, I nearly uploaded a commit which changed that file to a plain text file containing the text ../CHANGELOG.rst 🙁

For portability, it might be better not to include symlinks in the repository...

@FFY00
Copy link
Member

FFY00 commented Mar 19, 2021

Uh, I thought symlinks were fixed on Windows, I guess that's not the case.

@gaborbernat
Copy link
Contributor

I mean could be Paul doesn't have symlinks enabled 🤷‍♂️

Copy link
Member

@FFY00 FFY00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than this, it should be good! Thanks 😊

CHANGELOG.rst Outdated Show resolved Hide resolved
@pfmoore
Copy link
Member Author

pfmoore commented Mar 19, 2021

I do have symlinks enabled, and they do work. I suspect that the problem is that git might not handle them. I'm using a very vanilla git setup.

@pfmoore
Copy link
Member Author

pfmoore commented Mar 19, 2021

@gaborbernat I've raised #262 with details of the pre-commit failure.

@FFY00 I think I've done everything needed now. I've no idea why the coverage has gone down (or what I need to do to fix that). The coverage report seems to be flaggking lines that I haven't touched as uncovered 🙁

Let me know what (if anything) more I need to do.

@FFY00
Copy link
Member

FFY00 commented Mar 19, 2021

Thanks! The coverage is a bit fiddly, it is fine now.

@FFY00 FFY00 changed the title Validate the source directory passed to ProjectBuilder build: validate the source directory passed to ProjectBuilder Mar 19, 2021
@FFY00 FFY00 merged commit 2c1da83 into pypa:main Mar 19, 2021
@pfmoore pfmoore deleted the check_setup_py branch March 19, 2021 14:12
@pfmoore
Copy link
Member Author

pfmoore commented Mar 19, 2021

Thanks @FFY00 and @gaborbernat for the help getting this PR through 🙂 Much appreciated.

Copy link
Contributor

@gaborbernat gaborbernat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise looks good.

@@ -136,6 +136,18 @@ def test_check_dependency(monkeypatch, requirement_string, expected):
assert next(build.check_dependency(requirement_string), None) == expected


def test_bad_project(test_no_project_path):
# Passing a nonexistent project directory
with pytest.raises(build.BuildException):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you split each test into its own test please? 👌

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code already went in. This is not a big deal though.

@henryiii
Copy link
Contributor

Sorry I missed this. It's also valid to have setup.cfg but no setup.py or pyproject.toml.

@layday
Copy link
Member

layday commented Mar 24, 2021

It's not for legacy projects - how are you going to be able to invoke sdist or bdist_wheel? If it works in pip it must be because it calls setup() on the fly.

@pfmoore
Copy link
Member Author

pfmoore commented Mar 24, 2021

If there's no pyproject.toml then (in certain circumstances - it's complicated with all sorts of compatibility cruft) pip will use the setuptools.build_meta:__legacy__ backend, as suggested in PEP 517.

Also, see my comment here. In terms of PEP 517, there are only two sorts of source tree - ones with pyproject.toml and ones with setup.py. Nothing else is technically a Python source tree, if you accept PEP 517's definition.

@henryiii
Copy link
Contributor

henryiii commented Mar 24, 2021

Not having a pyproject.toml is not something I do, but setup.cfg only projects are valid, and currently work in build:

pipx run cookiecutter gh:scikit-hep/cookie
rm pyproject.toml
rm setup.py
pipx run build

This correctly produces a wheel and SDist, just like pip would. (Technically, I'm not sure how you would make an SDist without build, actually). Current master would now be broken. We suggest setup.cfg only projects on https://packaging.python.org/tutorials/packaging-projects/ (with a pyproject.toml too, of course, but technically it can be omitted and pip and current build work).

@henryiii
Copy link
Contributor

Quick followup, pip checks this:

python3 -m pip wheel .
ERROR: Directory '.' is not installable. Neither 'setup.py' nor 'pyproject.toml' found.

So being just as picky in build is perfectly fine. Though it is a removal of something that used to work.

@henryiii
Copy link
Contributor

As of pypa/pip#9945, we've now swapped with Pip. Pip 21.1.2 does support just setup.cfg now, and now we don't. 🤣

$ pip wheel .
ERROR: Directory '.' is not installable. Neither 'setup.py' nor 'pyproject.toml' found.
WARNING: You are using pip version 21.1.1; however, version 21.1.2 is available.
You should consider upgrading via the '/Users/henryschreiner/tmp/quickcheck/venv/bin/python3.9 -m pip install --upgrade pip' command.
$ pip install --upgrade pip
$ pip wheel .
Processing /Users/henryschreiner/tmp/quickcheck
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
Collecting numpy>=1.13.3
  File was already downloaded /Users/henryschreiner/tmp/quickcheck/numpy-1.20.3-cp39-cp39-macosx_10_9_x86_64.whl
Building wheels for collected packages: quickcheck
  Building wheel for quickcheck (setup.py) ... done
  Created wheel for quickcheck: filename=quickcheck-0.0.0-py3-none-any.whl size=3372 sha256=57acfb84109eedde21404ffdea6ef0e87d6ef7663498e3220bb0c4a72b066d35
  Stored in directory: /private/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/pip-ephem-wheel-cache-62ksr1uu/wheels/9a/34/3d/e8d9298f424ae357bac078a56990fce39937c7ed9018594f47
Successfully built quickcheck

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants