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 spaces to opam root during CI #634

Closed
jonahbeckford opened this issue Dec 30, 2022 · 4 comments
Closed

Add spaces to opam root during CI #634

jonahbeckford opened this issue Dec 30, 2022 · 4 comments

Comments

@jonahbeckford
Copy link

jonahbeckford commented Dec 30, 2022

It is very common to have spaces in directory paths on Windows (ex. C:\Users\Jane Smith) and is not unusual on macOS either. Packages should not fail to build simply because a user has a space in their path.

The suggestion is to change the opam root to include a space. Examples:

  • /home/runner/work/has space
  • /home/has space
  • D:/a/has space
  • C:/GitLab-Runner/builds/has space

The suggestion is to make the default in a new version of CI (ex. setup-ocaml.v2.1.0) use a space since it is a bug to not support spaces. However, if the field x-validation-path-with-spaces: false is present in all .opam files (can use awk to check), then no space should be used.

Eventually this change of opam root may make it into the opam repository CI. But this issue needs to be implemented first.

Cross-links:

@avsm
Copy link
Member

avsm commented Dec 31, 2022

I'm fine with adding this change in by default. I can't think why the x- field is needed -- either we want to support Windows and macOS users-with-spaces or not. Any reasonable build system really should just work, and failing unconditionally should be a good prompt to other systems to fix their quoting.

@jonahbeckford
Copy link
Author

I'm fine with adding this change in by default. I can't think why the x- field is needed -- either we want to support Windows and macOS users-with-spaces or not. Any reasonable build system really should just work, and failing unconditionally should be a good prompt to other systems to fix their quoting.

I suspect we'll run into unfixable problems with build systems that are still kicking around in OCaml:

Perhaps I'm being too pessimistic?

@avsm
Copy link
Member

avsm commented Jan 2, 2023

This CI should really be used to confirm a hypothesis (that the package should work with spaces in its username), and to closely match what users themselves do. If we already know that things will fail with spaces in them, with no workaround apart from renaming the user, then what's the point in CI support for it? One pkg-config failure is enough to scuttle a build, and a grumpy user is the result :-)

Conversely, you've identified something we should fix in the opam repository: we could start working our way through pkg-config uses and come up with alternatives. I've wanted a more central solution for library configuration management as an overlay in dune-configurator for a while...

@jonahbeckford
Copy link
Author

Okay. Consider me convinced! Let's just start with identifying packages that don't work with spaces, and see where that goes.

@smorimoto smorimoto closed this as not planned Won't fix, can't repro, duplicate, stale Jan 16, 2023
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

No branches or pull requests

3 participants