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
Windows 10 Pathing issue on Ruby node_modules #100
Comments
That's very strange. I don't have a Windows machine, so could you create a git repo of just that code so that I can run it on appveyor? |
This could be related to the long pathing issue. @mattstankey can you reduce the path length of your project and see if it works? If it doesn't, could you recreate a small demo project and put it somewhere for me to try on my machine? Thanks. |
I can confirm that this issue is related to the long path limitation of windows. Feel free to fix it on windows by setting the appropriate registry key. |
Yes, after moving the project to C;/[project_name] it does work for me. It looks like this is an issue with Windows 10 path length. I'm not sure if it is specifically related to Ruby or not, but it doesn't seem to be related to pact-node. Thanks! |
@mattstankey did you see my solution above? |
I imagine this is a limitation of Ruby in Windows 10 with long path support. I don't know what you need to overcome this since MS doesn't have this limitation anymore. However, it is opt-in, even on more current builds.
https://bugs.ruby-lang.org/issues/12551 I can confirm that this is still an issue with https://github.com/pact-foundation/pact-node/blob/master/README.md#enable-long-paths enabled and moving this to a shorter directory path like like a root drive like /c/myapp or /d/myapp the problem goes away. Python 3.x and Node for example seem to work fine with long paths on windows when you have opted in of course. I hope this helps. |
@LeeGDavis Why would it be a ruby limitation if it only happens in Windows? I do believe the file access is done with C in ruby, hence it should be using the windows file api and should adhere to the long path solution. |
@mboudreau I would say it is a limitation in Ruby based on its usage of the underlying c runtime. It is a relatively new thing vendors have started to support, I think mid 2016. My assumption is they haven't taken the steps necessary to fully implement whatever is needed to support long paths. I believe it has to do with how file names are referenced, so that different versions of the api are called that support long paths. It seems they know about the issue and I imagine someone in the community will tackle this. |
Maybe, but I had enabled long paths on my windows box and found I couldn't
go more than 260 characters, which is weird... Again, not sure if this is
related, but trying to dig deeper into the horrible abyss that is Windows.
…On Thu, Jul 19, 2018 at 1:28 PM Lee Davis ***@***.***> wrote:
@mboudreau <https://github.com/mboudreau> I would say it is a limitation
in Ruby based on its usage of the underlying c runtime. It is a relatively
new thing vendors have started to support, I think mid 2016. My assumption
is they haven't taken the steps necessary to fully implement whatever is
needed to support long paths. I believe it has to do with how file names
are referenced, so that different versions of the api are called that
support long paths. It seems they know about the issue and I imagine
someone in the community will tackle this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#100 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAjA5CRQijbqS3vFyyC8FJwNjr4MXuuzks5uH_zVgaJpZM4VNXmJ>
.
|
@mboudreau have a look at this issue https://bugs.ruby-lang.org/issues/12551. While I don't know if this is exactly representative of what is being observed here, I imagine it is related. They even reference the long path prefix |
@LeeGDavis I might have found a solution, but dropping the binary files in the user's tmp directory, which should be a lot less long. Let me try it out and I'll release a new fix version and see if that helps you in your situation. |
hey @LeeGDavis, I think I may have a fix for you. #103 Maybe you'd want to pull the files, build and test it out. It should download the binaries to the temp directory, which should be a lot less long than your project path. Cheers, M |
@LeeGDavis @mattstankey disregard my last comment, I've released a version, |
@mboudreau I can't seem to locate that version. Is there anything special I need to do to pull that down? |
@LeeGDavis Sorry, seems like it had skipped the deployment, my bad. I redeployed it properly now, please try again. |
@mboudreau Looks like this is still an issue, however this error looks different. I hope this stack trace helps:
|
Okay, that's better. I means that the Pact binary is running, but now the binary is having issues opening the file that's more than 260 characters. We might be able to fix this. @bethesque As per Microsoft's article, could you maybe have the binary prepend |
If the ruby code needs changing, I can do that, but I think you should be able to pass in the path with the right prefix? |
@bethesque I can to just test it out, however, I think it should be fixed from the Ruby end since this particular issue would affect every language that uses it. |
Fair point. See how it goes. |
Hi, did anything ever happen re: the |
Try looking at the latest (beta) v3 branch for pact js (it won't have this issue) and also has support for v3 matchers and XML. Pact node is not a dependency for the v3 parts of that code and should be 👌 EDIT: the v3 version can be obtained through npm, see https://github.com/pact-foundation/pact-js#pact-js-v3 for instructions. |
Thanks for the suggestion @mefellows, pact js v3 isn't giving me this issue any more - but now the mock service is refusing connections! (edit: testFn was missing a return statement. now getting an actual, workable test failure) |
Thanks for the update - I wonder if we can check for the correct shape of the function and error better. |
Hi All, I am also getting this error on windows machine. Is there a solution for this already? |
The solution is described above @pulgupta |
Closing as latest version removes Ruby and this issue. |
Hi,
I am trying to test some service endpoints with Pact using Windows 10. I am getting a strange ruby error on the require statements on line 1 of the node_module packages when running ./node_modules/.bin/jasmine. The same tests run fine on a Mac, but throw the error stacktrace shown below on Windows. Here are the following details for the Pact libs:
Here is the test I am trying to run:
Error Stacktrace:
Please let me know if I need to add more information here.
The text was updated successfully, but these errors were encountered: