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

Make buidler work on windows #439

Merged
merged 21 commits into from
Feb 12, 2020

Conversation

fvictorio
Copy link
Member

This PR has some initial changes to make buidler work on windows.

  • The scripts/install.sh and scripts/run-tests.sh scripts were rewritten in shelljs.
  • A GitHub action was added.
  • cross-env is used to make relative paths in scripts work. But, for this to work, the deletion of .bin directories in the install script was commented out. This makes the whole purpose of using a relative path in the packages scripts unnecessary, so cross-env could just be replaced with the local binaries.

The run-tests.sh scripts inside each package weren't migrated yet.

@fvictorio fvictorio requested a review from alcuadrado February 9, 2020 16:32
@fvictorio
Copy link
Member Author

This is the last run in actions for this: /~https://github.com/fvictorio/buidler/actions/runs/36616440 which failed because it couldn't find cross-env. A previous run with pretty much the same configuration did pass /~https://github.com/fvictorio/buidler/actions/runs/36588608 Not sure how to fix this.

One approach that I'm pretty sure would work for sure is to have cross-env installed in the root node_modules, and then do this moutful in each script:

"build": "node ../../node_modules/cross-env/src/bin/cross-env.js ../../node_modules/.bin/tsc --build src",

which:

  • Use cross-env so that environment variables and relative paths work
  • Run cross-env using the node path/to/bin.js trick recommended in this answer
  • Use the binary (tsc in this case) installed in the root directory

It goes without saying that this is convoluted and ugly. My guess is that the proper solution is related to fixing the problem with lerna and package binaries, but I have no idea what the problem is and how to fix it.

@fvictorio
Copy link
Member Author

My bad, I forgot to add node scripts/install.js to the CI. It was working before because it was in a postinstall, but I'm not sure if it's safe to have it there.

Here's the action in action: /~https://github.com/fvictorio/buidler/runs/434787498

The tests step passes because the shelljs scripts aren't throwing when a command fails. I will fix that next.

The windows runner in GitHub Actions has autocrlf set to true by
default. This means that files are checked out with CRLF line endings,
which causes the linter to throw a lot of errors. This should fix that.
@fvictorio fvictorio force-pushed the work-in-windows branch 2 times, most recently from 15bf5b8 to 46b6e95 Compare February 12, 2020 00:33
@@ -59,8 +60,8 @@ describe("Typescript support", function() {
});

assert.deepEqual(tests.sort(), [
await fsExtra.realpath("test/js-test.js"),
await fsExtra.realpath("test/ts-test.ts")
await fsExtra.realpath("test/js-test.js").then(slash),
Copy link
Member

@alcuadrado alcuadrado Feb 12, 2020

Choose a reason for hiding this comment

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

I don't get why these need to be slashed. They are file paths.

Copy link
Member Author

Choose a reason for hiding this comment

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

TASK_TEST_GET_TEST_FILES returns the files with unix slashes, even in windows. I thought it was easier to change the tests than the functionality.

Copy link
Member

Choose a reason for hiding this comment

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

That's surprising, and will probably lead to bugs in the future.

I think the problem comes from our glob module. I'd rather normalize the paths to use the system's separators before returning them from it. This means modifying glob and globSync.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I thought about that but it seemed a little out of scope. I will do it now 👍

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 fixed it adding the realpath option to the glob utils. This fixes the problem and the test passes in both linux and windows. The docs have a caveat:

realpath Set to true to call fs.realpath on all of the results. In the case of a symlink that cannot be resolved, the full absolute path to the matched entry is returned (though it will usually be a broken symlink)

But that doesn't seem like it will be an issue here.

@@ -36,8 +36,12 @@ describe("Scripts runner", function() {
);
assert.equal(statusCode1, 0);

const statusCode2 = await runScript("./failing-script.js");
assert.notEqual(statusCode2, 0);
const statusCode2 = await runScript(
Copy link
Member

Choose a reason for hiding this comment

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

Why was this change needed?

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 don't remember if the extra arguments were needed. The check for 123 was because at some point this tests was (wrongly) passing when the script failed with a 1 exit code.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I see. Good catch! Can we leave the 123 and remove the extra params if they aren't necessary?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done. It passes on my machine, will see if they continue to pass on windows (it would be extremely weird if they don't).


shell.config.fatal = true // throw if a command fails

const isLinux = os.type() === "Linux"
Copy link
Member

Choose a reason for hiding this comment

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

Can we do isWindows instead? This script is also used during development, and many contributors use mac.

Copy link
Member Author

Choose a reason for hiding this comment

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

The isLinux variable is only used for ignoring the buidler-vyper tests in windows and mac. In windows, docker is available but defaulting to windows containers and changing it to linux containers is not straightforward (at least I wasn't able to do it easily). In mac, inside github actions, docker is not available for, I think, licensing reasons.

@alcuadrado alcuadrado changed the base branch from master to windows-support February 12, 2020 21:39
@fvictorio fvictorio marked this pull request as ready for review February 12, 2020 22:18
@alcuadrado alcuadrado merged commit c6afc31 into NomicFoundation:windows-support Feb 12, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants