-
Notifications
You must be signed in to change notification settings - Fork 108
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
Conversation
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. |
The same rules have been enforced in the I generally use one of several libraries for messages and errors so making a separate error message routine seems like a good |
Co-authored-by: Sebastian Ehlert <28669218+awvwgk@users.noreply.github.com>
@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. |
There was a problem hiding this 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.
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. |
There was a problem hiding this 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.
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.