Skip to content

Conversation

@markhuot
Copy link
Contributor

this is helpful if your project root/bin folder is not the same as where your typical PWD is. For example, we'll usually have the project root contain the bin folder but the artisan or ./craft CLIs live inside a html directory. In this case you could now run cog from inside the html dir and it would still find ../bin/cog-* files.

To test this out the PR also adds a cog issue command that you could run with a project. E.g., you could run cog issue 123 inside a project directory and your browser would open with the correct URL.

this is helpful if your project root/bin folder is not the same as where your typical PWD is. For example, we'll usually have the project root contain the bin folder but the `artisan` or `./craft` CLIs live inside a `html` directory. In this case you could now run `cog` from inside the `html` dir and it would still find `../bin/cog-*` files.
@dreadfullyposh
Copy link
Collaborator

I'll check this out.

Copy link
Collaborator

@dreadfullyposh dreadfullyposh left a comment

Choose a reason for hiding this comment

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

Looks good to me. I have slight pause since the project .cogconfig could override the global and blow up the plugins you have installed, but not enough to hold up releasing this.

@markhuot
Copy link
Contributor Author

Agreed on the project .cogconfig conflicts. However, it could almost be treated like path though with something fun like this,

COG_PLUGIN_DIRECTORIES="$COG_PLUGIN_DIRECTORIES,/my/project/plugins"

@dreadfullyposh
Copy link
Collaborator

SHIP

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.

2 participants