-
Notifications
You must be signed in to change notification settings - Fork 167
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
/bin particulars #39
Comments
Interesting, the README.md does not delimit the difference between CLI tools that are part of the package or provided by the package as a deliverable. It does say "...If the package provides a root-level directory for command-line executable files, it MUST be named As for other CLI tools...If What are you thoughts about this @cxj ? |
I don't have a strong feeling one way or the other about using For example, I have written a number of packages where the end result of a compile-like step produces a As I said, though, I don't really have a strong case for either choice. I was hoping to get Paul's response. |
I personally put both categories there. It's the least surprise. See Rector package: https://github.com/rectorphp/rector/tree/master/bin These are used by programmer who uses this package as dependency:
The rest is for package contributors. Also, for composer you can specify files that should be used by public: https://getcomposer.org/doc/articles/vendor-binaries.md#how-is-it-defined-, so there is no reason to create multiple directories for public and contributor use. |
Are the command-line executables which belong in /bin those which are delivered as part of the package? Or are they executables which are generated by the package, after delivery and installation, via some user-invoked means? Or both?
The text was updated successfully, but these errors were encountered: