Page MenuHomePhabricator

Feature request: Release arcanist as Phar package, to reduce the cost (download, redistribute, update, mantain)
Closed, InvalidPublic



To provided a more easy obtain executable binary package for

The problem

  1. Install arcanist need clone both arcanist git repository and libphutil.
  2. It takes too long time to clone these two repository
  3. It not very stable for update to a latest release version (arcanist), git pull may bring some not stable commit in.
  4. we using svn , not git as our VCS. so we do not expect to install git on each team member's pc

Try to resolve problem

Is it possible arc client bin released as a phar package?
if we can release a pre-built phar file, it will be more easier to deploy on each team members pc.
For example. the phpunit.phar and the composer.phar very easy to obtain. and easy to running .

We can gain these benefit from the new phar package.

  • Easy to download, just one phar package
  • Easy to deploy. just copy it to each members pc
  • Easy to use, just run
php arc.phar
  • Easy to update, Just download new phar file and replace it
  • Not required to install git ..

Event Timeline

chad added a subscriber: chad.

See Contributing Feature Requests for what information is required for a feature request.

Well, i have not found a feature request template. but i tried to explain why i post this feature request.

You didn't see this at the top of the Feature Request form?

pasted_file (358×1 px, 62 KB)

netroby updated the task description. (Show Details)
netroby renamed this task from Is it possible arc client bin released as a phar package? to Feature request: Release arcanist as Phar package, to reduce the cost (download, redistribute, update, mantain).Dec 16 2016, 6:32 AM

@chad. i tried to explain why i post the feature request. it it ok? valid for feature request requirement?

Not really, I'm still not sure what the root problem is. It mostly sounds hypothetical. In general you're asking us to do weeks of work to save 1 engineer 5 seconds, 1 time over the course of their job. At least, it seems like if those few seconds are so vital, that you'd script all developer tool installations with one script. I don't see what 2 repositories vs. 1 solves.

T6012 covers composer, T4200 covers alternate installation methods. In general, I'd assume you're installing all developer tools (if you're a large org) via some scripts, and scripting the installation of arc/git, is trivial. arc upgrade can be ran locally to keep developers up to date.

OK. to decrease the deploy cost. i would like to contribute the project. try my best to do this work. I am not ask you provide it for me . Is it an opensource project? Every one can contribute it ? but i still need your guide. if i want implements. what the problem block us do the work?

T5055 also covers distribution of linters/etc via arcanist as a package manager.

Unfortunately this probably isn't something we'd pursue in the upstream, so we won't likely take code into the upstream for it. We allow people to share things like this though on the Community Resources page in Phriction

There are many tasks here that I mentioned that explain our reasoning around this. Our main concern with any contribution is the long-term maintenance and documentation. These generally exceed the initial time input of the feature. For example, until you mentioned "phar", I had never heard of this mechanic of distribution before. We'd be signing up to document and support people who'd want to use that feature (of which we have none right now other than yourself).

This guide has a more detailed explanation of our contribution practices: