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

Add bash script to autotest cpython lib #4870

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

MegasKomnenos
Copy link
Contributor

#4564

The following PR contains a bash script to automate the initial testing workflow for updating python library components from cpython.

The workflow includes selecting and updating an individual library component, then running the related test to search for bugs. I realized that this work can be automated and be run for every library components, to screen out ones that fail. I wrote a bash script that does that, and made this PR.

To use, write down your local cpython path in clib_path.txt, and run,
bash clib_test_one.sh

and check the result in clib_out.txt

The script will try to test every component in clib_list.txt, where,

clib_test_one.sh : test each component individually
clib_test_all.sh : test every components simultaneously
It works by making the code to ignore every tokens that come after the comment symbol
It fails in a weird way and crashes the whole system by gobbling up memory
scripts/clib/readme.txt Outdated Show resolved Hide resolved
To use, add # in front of any line that you want to comment out
Warning, it won't work unless # is the first character in a string, not including whitespaces
@youknowone youknowone added the skip:ci Skip running the ci label Apr 20, 2023
@youknowone
Copy link
Member

Thank you! let me test it a bit.


If either of those assumptions are false, then you must provide a correct path when running clib_test.py

The script will try to test every component in clib_list.txt
Copy link
Member

Choose a reason for hiding this comment

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

how did you made clib_list? manually or by script?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I copy-pasted the content of the issue page into a txt file, then used regex to filter out its contents

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 be relatively easy to keep clib_list in sync with the release of Python we target.

scripts/clib/clib_out.txt Show resolved Hide resolved
scripts/clib/clib_test.py Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved
message.append(f"No cpython/Lib/test/test_{lib}.py")

if test_do:
result = subprocess.run(["cargo", "run", "-q", f"{RPYTHONPATH}/Lib/test/test_{lib}.py"], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
Copy link
Member

Choose a reason for hiding this comment

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

using cargo run in loop is bad idea because it will run cargo build every time.

I will use ../../target/release/rustpython here, and call cargo build --release only once before loop

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But wouldn't it be necessary to do cargo build each time as we're changing its library files? Or maybe the interpreter functions independent of its library python files and simply references whatever is written there when it needs to? I'm not familiar with the structure of the project and I assumed the former to be true, but maybe it's not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Huh. I'm seeing an odd change in behavior. I'm comparing the previous result stored in clib_out.txt with the new result that I'm getting from this change, and it seems to be slightly different? Some tests that failed before now are now passing. Odd.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe that this command is not working as intended.

result = subprocess.run(
[RUSTEXECPATH, "-q", self.path_tpython_test],
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
env={"RUSTPYTHONPATH": "/home/kjh/20231/rust/RustPython/LibTest"}
)

When I run it with the Lib directory removed, it returns ModuleNotFoundError

@youknowone
Copy link
Member

Any suggestion about the script name? clib doesn't give good sense what the script does.
We may be able to turn this script to auto-updating trivial cpython library easily.

cc @fanninpm @DimitrisJim

scripts/clib/clib_test.py Outdated Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved
scripts/clib/clib_test.py Outdated Show resolved Hide resolved

if os.path.isfile(f"{RPYTHONPATH}/Lib/{lib}.py"):
lib_exist = True
os.rename(f"{RPYTHONPATH}/Lib/{lib}.py", f"{RPYTHONPATH}/Lib/{lib}_tmp_mv.py")
Copy link
Member

Choose a reason for hiding this comment

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

Rather than renaming original library files, redefining RUSTPYTHONPATH will be fine.

This is the logic I think.

  1. cp -r Lib LibTest (but in python, not shell)
  2. cp ../cpython/Lib/x LibTest/x
  3. RUSTPYTHONPATH=LibTest rustpython Lib/test/test_...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, that would be easy. But I am not fully grasping why that would be a better design. Is it because messing with library files via script may open room for possible human mistakes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've tried to use RUSTPYTHONPATH environment variable to control which library files are referenced by rustpython interpreter but I seem to be doing something wrong, as it's working as if it's still referencing files in Lib, not LibTest. Could you guide me through how I could do what you suggested in python?

Copy link
Member

Choose a reason for hiding this comment

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

This is same as build script principle. Build script shouldn't edit source code but create artifact only under build directory.
By isolating build directory from source code, it is guaranteed to be reproducible regardless current state of the source code. Also by avoiding editing current state, catching a mistake is easier by missing files and no worries to make bugs not to correctly edit/recover original files to both the build script and the source code itself.

Not tried myself yet, but how did you set environment variable? It will look like:

subprocess.run(
                ["rustpython", "-q", self.path_rustpython_test],
                stdout=subprocess.PIPE, 
                stderr=subprocess.STDOUT,
                env={"RUSTPYTHONPATH": "LibTest"},
            )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried to set environment variable through os.environ. Let me try again with a new method and see how it turns out.

scripts/clib/clib_test.py Outdated Show resolved Hide resolved
Changed code structure to prevent rebuilding cargo for each iteration of the loop
Made the script to no longer edit the lib files directly, and instead used RUSTPYTHONPATH to reference a temporary lib folder
@@ -0,0 +1,153 @@
__future__: OK
Copy link
Member

Choose a reason for hiding this comment

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

So this is typically the output of running clib_test.py, right?

@DimitrisJim
Copy link
Member

do we have any updates on the state of this PR? It's been sorta stale for 3 weeks now and we should try and get your work through soon if possible.

@youknowone
Copy link
Member

My bad, I forgot about this after getting in the parser rally.
The whole idea is awesome. I need to clean up its interface more fit in our other scripts and naming so on.

@youknowone
Copy link
Member

@DimitrisJim do you have a good name suggestion instead of clib? it is not a C something.

@DimitrisJim
Copy link
Member

ah, sure, I can pick this up and get it through with @MegasKomnenos. Parser is definitely a more pressing issue so you can give as much attention there as needed.

a good name suggestion instead of clib?

Yeah, clib is not the best too imho. I'd be fine with autotest as the title uses, the README should explain any additional information needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip:ci Skip running the ci
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants