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

/bin particulars #39

Open
cxj opened this issue Aug 4, 2017 · 3 comments
Open

/bin particulars #39

cxj opened this issue Aug 4, 2017 · 3 comments

Comments

@cxj
Copy link
Contributor

cxj commented Aug 4, 2017

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?

@davidjeddy
Copy link

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 bin/....". To me that reads as any CLI executable provided by the package, IE the result of composer install {package}, belong in ./bin. So that covers commands the package implements.

As for other CLI tools...If ./bin is good enough for commands created by the package, why not for other executable? I guess ./tools or ./misc or ./helpers could also work.

What are you thoughts about this @cxj ?

@cxj
Copy link
Contributor Author

cxj commented Aug 24, 2018

I don't have a strong feeling one way or the other about using ./bin for all CLI tools, regardless of source or purpose. But I can imagine that separating them might make sense in some cases.

For example, I have written a number of packages where the end result of a compile-like step produces a phar file that can then be installed on any system hosting a copy of PHP. The Composer pieces and the entire skeleton will never be seen by the end user. In such a case, maybe it makes sense to have my compile process output to a different directory than ./bin for clarity, if nothing else.

As I said, though, I don't really have a strong case for either choice. I was hoping to get Paul's response.

@TomasVotruba
Copy link

TomasVotruba commented Sep 7, 2018

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:

  • rector
  • bootstrap.php
  • container.php

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.

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