8000 check name used for package, executable, test, or example by urbanjost · Pull Request #511 · fortran-lang/fpm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

check name used for package, executable, test, or example #511

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

Merged
merged 7 commits into from
Jul 16, 2021
Merged

check name used for package, executable, test, or example #511

merged 7 commits into from
Jul 16, 2021

Conversation

urbanjost
Copy link
Contributor
@urbanjost urbanjost commented Jul 9, 2021

fpm manifest files can contain names that produce errors or complicate keeping the package portable. The names are used as parts of file names and even module names but are not tested for spaces, slashes, and other special characters. Although there may be interest in allowing Unicode names or other syntax in the future, fpm will generally produce errors internally if anything other than ASCII alphanumeric characters are used for names, plus a hythen and underscore; and names should start with a letter.

This adds such a check and also replaces ERROR STOP calls with STOP calls, which is generally distracting and usually not useful; although it has been useful during early development of fpm for developers.

This should prevent the problems described in #503, although adding such a note to the documentation would be appropriate as well. Closes #331 "feature" also.

@LKedward LKedward requested a review from awvwgk July 10, 2021 09:23
@LKedward
Copy link
Member

Thanks @urbanjost - this all looks fine with me, but I can't remember whether we discussed what the rules are for package names since this PR tightens those rules considerably.

@urbanjost
Copy link
Contributor Author

The same rules have been enforced in the new subcommand for quite a while, with the recent change to allow hyphens. When using new the name is actually used for directory names and module names and so it can be very problematic to allow other characters; and although it could be changed it is used in system commands so spaces, asterisks, and other characters become problematic very quickly; but this issue even appeared in the tests where some of the test names contained a pound character (#). So the only way to get a non-conforming name has been to manually create or edit the fpm.toml file for quite a while; but I did a scan of github trying to see if I could find a package it would break because this inconsistency has probably become a feature for someone by now, and did not find one.

I generally use one of several libraries for messages and errors so making a separate error message routine seems like a good
long-term idea; and would allow for support of multiple languages and color and verbose mode doing an error stop versus regular mode doing a stop, etc. In this case I was trying to minimize the changes but up until recently the error messages were more for the developer than the user so something fancier would be good, but was just trying to do an incremental improvement here on that aspect of things and just get a warning message to the user that would solve the PR. Had been hoping something like a full blown message system would emerge via stdlib. I could turn one of mine into an fpm package, or we could look at where stdlib stands on this; but while doing this I thought it would complicate the issue a bit at that time; and related PRs (adding color as in one of the other PRs would start laying the groundwork for a message handling system, for example) I did not start going down that path yet, but yes, I think the messaging/error handling is ripe for a revamp now that so much more is production-ready.

@urbanjost
Copy link
Contributor Author

@awvwgk Don't want to conflate this PR too much, but took a first step towards addressing some of the messaging per above; so all STOPs are via FPM_STOP. Makes it a lot easier to control the format/action takens and standardize the appearance of the messages. Can dress it up a bit with colors and a traceback in verbose mode but that can be done a lot more cleanly after a few other changes are made in other PRs. Changed things enough it needs another look.

Copy link
Member
@awvwgk awvwgk left a comment

Choose a reason for hiding this comment

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

Thanks a lot. This looks good to me now.

@urbanjost
Copy link
Contributor Author

PR is removed from version information, and I replaced all the remaining STOP calls with FPM_STOP. I want to make a more generic verbose mode, and then FPM_STOP can conditionally call ERROR STOP, or perhaps use color. Thinking taking an array instead of a single string would allow for longer messages with info like a pointer to the column where the error occurs as mentioned, but want to do that in a separate PR if the latest few work out (they are indirectly related to doing that). Hopefully this gets everything in position for that.

Copy link
Member
@LKedward LKedward left a comment

Choose a reason for hiding this comment

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

Thanks @urbanjost, this all looks good to me and thanks Sebastian for reviewing.

@LKedward LKedward merged commit 68937a4 into fortran-lang:master Jul 16, 2021
@awvwgk awvwgk mentioned this pull request Sep 5, 2021
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.

name="executable-name" allows names with slashes
3 participants
0