Skip to content

Conversation

ev-br
Copy link

@ev-br ev-br commented Aug 28, 2025

This is WIP, get some 15 test failures locally. Updated according to an off-line discussion. CI tests pass with both pytest and bazel, at ev-br#1


📚 Documentation preview 📚: https://google-grain--1013.org.readthedocs.build/

ev-br added 3 commits August 28, 2025 13:37
Otherwise, `pytest` tries collecting it because it starts with Test
Install the data files, and get their paths relative to the installed `grain`
package
pyproject.toml Outdated
Copy link
Collaborator

Choose a reason for hiding this comment

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

do we need to package the data?

i was hoping the we can eventually exclude the test files and the data from the wheel file

Copy link
Author

@ev-br ev-br Aug 29, 2025

Choose a reason for hiding this comment

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

In general, the package installed from a wheel knows nothing about the source: the wheel can in principle be installed on a different machine, for instance.

Are you thinking about two wheels, one for grain itself, and the other for grain-tests? Then the data files will only need to be included into the second one. But that would imply a larger reshuffling of test modules (for one, they'll need to move out of the main grain source tree).

Copy link
Collaborator

Choose a reason for hiding this comment

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

I was thinking more like run test files from the source against the installed grain version, but we can come back to this at some point later

Copy link
Author

Choose a reason for hiding this comment

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

As far as I undertsand, this still requires some information about where to find these data files to get into the wheel. We can surely install a text file with a path to the source if that's what you're after. Feels a little unusual, TBH.

Copy link
Contributor

Choose a reason for hiding this comment

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

Building with Bazel and running test with pytest causes this gap of information for pytest to where to find test-related data files.

In my opinion, for now we can package test-related files with the wheel, to run them with pytest - I think this change is simple enough that it doesn't cause much maintenance burden.

If in the future, the test suite data grows so large so that packing it with the wheel is unfeasible, then we could amend the build setup by moving test files manually in the build_whl.sh for testing phase - but this complication (which always needs to be maintained) to the build process makes sense when there's a valid need for it. WDYT?

import grain
if grain.__file__ is None:
# tests run under bazel
self.testdata_dir = pathlib.Path(FLAGS.test_srcdir) / "testdata"
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we try setting this flag in the pytest scenario somehow?

Copy link
Author

Choose a reason for hiding this comment

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

Okay, done now. Both ways of running tests seem to pass on my fork, ev-br#1

Copy link
Collaborator

Choose a reason for hiding this comment

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

pytest seems to have a fixture api through a conftest file that allows to provide initialization functions, e.g. in https://docs.pytest.org/en/stable/reference/reference.html#pytest.hookspec.pytest_sessionstart

the reason why I'm suggesting this is that the conftest.py file would be shared across all tests + would only be relevant to pytest automatically. As is, we'd have to update every test accessing local file system

Copy link
Author

Choose a reason for hiding this comment

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

Currently the updated PR uses module-level fixtures in the modules which actually need this. We can make it into a session-level fixture, if you are not happy with module-level fixtures?

@iindyk
Copy link
Collaborator

iindyk commented Sep 8, 2025

looks great, thanks! I'll work on importing this change internally

copybara-service bot pushed a commit that referenced this pull request Sep 9, 2025
Ported from #1013

PiperOrigin-RevId: 805035450
copybara-service bot pushed a commit that referenced this pull request Sep 9, 2025
Ported from #1013

PiperOrigin-RevId: 805035450
copybara-service bot pushed a commit that referenced this pull request Sep 9, 2025
Ported from #1013

PiperOrigin-RevId: 805035450
copybara-service bot pushed a commit that referenced this pull request Sep 9, 2025
Ported from #1013

PiperOrigin-RevId: 805035450
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.

3 participants