In T15096#2233, @speck wrote:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Definitely agree that the effort to set up arcanist isn't huge. And at my current work, it's baked into our common Dev PC setup, so it's almost zero effort. But there is an effort, and a dev/user who is just passing by to fix a typo or suggest a one-line change in some code isn't going to be willing to do that effort.

@micax: Good points and it's helpful to hear another perspective on this. From my past experience using Phabricator on a corporate team I definitely think that arcanist helped keep everyone's workflow consistent and simple.

I find this rather interesting (and a little bit weird, to some extent), because IMO the arcanist command line tool is one of the things which IMO _add_ value to Phabricator and sets it apart from it's alternatives.

Might be worth it having the linter classes inherit from a language-specific class that would handle things like environment initialization and dependency installation.

Yeah, I think we'd like to try and update arcanist to account for this with a general solution if possible and not making updates for each individual linter which might necessitate this. There's probably some general restructuring that needs to happen to account for the same odd scenario with Java and so forth.

Checking the source in Arcanist repo, it seems like none of the python linters are actually configured to use an interpreter. (If I attempt to specify one for Pylint anyway, it fails with Got unexpected parameters: interpreter)

I think that's roughly what I ended up doing in https://secure.phabricator.com/D14632 for launching separate Java linters, where java had to be configured as the "interpreter" and checkstyle.jar (or whatever) configured as the "binary" (https://secure.phabricator.com/D15067 added the ability to pass flags to the "interpreter").

Modern(ish) linters support a separate "interpreter" config - if that's set, they run $interpreter $binary $args rather then just $binary $args. Can this be utilized?

Right now,arc lint doesn't really allow for the activation of a virtual env. That's okay when I'm just running arc lint locally, because I can just activate the environment myself and run it in that environment.

Should this be the responsibility of the linter/tester and not part of Arcanist itself? Updating arcanist to handle the many different environment-dependent systems for languages would mean accounting for nearly every language like Javascript/npm, Ruby/rubyenv, etc. right?

I've left a comment on the server-side diff.

I submitted a draft revision for this. It's not quite complete yet, but anyone interested can take a look at it.

Oh my, sorry for the noise; my search-foo didn't find that.

This is a duplicate of T15051 and potentially solved with D25023