1
0
Fork 0
mirror of https://we.phorge.it/source/arcanist.git synced 2024-12-02 03:32:41 +01:00
Commit graph

10 commits

Author SHA1 Message Date
epriestley
c64f86c2f6 [Wilds] Flesh out most of the new Config objects
Summary:
Ref T13098. This is pretty rough, but sketches out the general shape of a more modern configuration flow. The new flow is very similar to the Phabricator flow.

Each configuration option is typed (string, bool, list of dictionaries, etc) so we can typecheck it, and each type is a class so the types are modular and can do fancy stuff. Some of this "fancy stuff" that I want to do includes:

  - transparently rewriting/reformatting various options for modernness/consistency;
  - having some options exposed as objects instead of raw JSON values (in particular, aliases);
  - merging "list" options (like "aliases") in a modular way instead of by having hard-coded stuff that says "this particular option is magic gets merged instead of getting replaced when defined in multiple places".

Generally, this makes everything modular and extensible and gets rid of the hard-coded `switch (...)` stuff.

Test Plan: Ran `arc get-config`, it sort of almost worked.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19695
2018-09-21 16:57:57 -07:00
epriestley
412484022b [Wilds] Prepare for more modular configuration management
Summary:
Ref T13098. This is kind of a catch-all diff with stuff that didn't fit in prior diffs, and which fixes some bugs with that stuff now that I made it at least sort of reachable.

Beyond bugs, the general idea is to replace `ConfigurationManager` (a big class which knew about config-end-to-end) with a more modern/modular `ConfigurationEngine` using the standard Engine + EngineExtension modularity pattern.

Configuration becomes a `ConfigurationSourceList` of `ConfigurationSource` objects, each of which represents one source (a config file, `--config x=y`, etc). The various sources will have the logic to parse values (e.g., decode `x=y` flags or JSON files on disk). A new `--config-file` allows you to replace the system (`/etc/arcconfig`) and user (`~/.arcrc`) files.

This also gets rid of `--library` support entirely for now since it's kind of messy to bridge until Config works. I expect to either restore it or replace it with `arc install` and similar.

Test Plan: Ran `arc liberate`; it actually works now. (The Config stuff does not actually work yet.)

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19694
2018-09-21 16:54:00 -07:00
epriestley
d936257018 [Wilds] Rewrite WorkingCopyIdentity in a more modern/modular way
Summary:
Ref T13098. Currently, `WorkingCopyIdentity` has rules for finding `.git/.svn/.hg` directories and `.arcconfig` files. It also has a ton of logic for reading and writing config files.

Generally:

  - Rename `WorkingCopyIdentity` to `WorkingCopy`.
  - Make it an abstract base with `Git`, `Mercurial` and `Subversion` subclasses, using the standard module/extension pattern.
  - Throw out almost all of the config file logic. This logic is going to move into Config classes. It is not unique to working copies.
    - Working copies retain the actual bit of this they need: knowing where stuff should go on disk.

This doesn't run yet, but sure looks a lot cleaner!

Test Plan: Doesn't run yet, since Config isn't working yet.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19689
2018-09-21 16:48:00 -07:00
epriestley
9a94aa216b [Wilds] Slightly simplify fatal handling during "arc" setup
Summary:
Ref T13098. We currently handle fatals by printing a message and returning an error code, since this was the most direct adaptation from the old `arcanist.php` script.

Instead, throw an exception and then handle it above, since we can reasonably do that in one place now.

Test Plan: Ran `arc`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19693
2018-09-21 16:46:05 -07:00
epriestley
fe0c293895 [Wilds] Remove include_path mangling and drop support for "externals/includes"
Summary:
Ref T13098. This logic comes from D3243 and was theoretically used to let you install `libphutil` with Homebrew. Since libphutil no longer exists and the other use cases I can come up with are questionable/obsolete, remove it.

(As we move into T5055, I expect to provide better tools for bundling/managing external dependencies.)

Test Plan: Ran `arc`, same as the old `arc`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19692
2018-09-21 16:44:11 -07:00
epriestley
8e0e07664a [Wilds] Remove libphutil
Summary:
Ref T13098. Historically, Phabricator was split into three parts:

  - Phabricator, the server.
  - Arcanist, the client.
  - libphutil, libraries shared between the client and server.

One imagined use case for this was that `libphutil` might become a general-purpose library that other projects would use.

However, this didn't really happen, and it seems unlikely to at this point: Phabricator has become a relatively more sophisticated application platform; we didn't end up seeing or encouraging much custom development; what custom development there is basically embraces all of Phabricator since there are huge advantages to doing so; and a general "open source is awful" sort of factor here in the sense that open source users often don't have goals well aligned to our goals.

Turning "arc" into a client platform and building package management solidify us in this direction of being a standalone platform, not a standalone utility library.

Phabricator also depends on `arcanist/`. If it didn't, there would be a small advantage to saying "shared code + client for client, shared code + server for server", but there's no such distinction and it seems unlikely that one will ever exist. Even if it did, I think this has little value.

Nowadays, I think this separation has no advantages for us and one significant cost: it makes installing `arcanist` more difficult for end-users.

This will need some more finesssing (Phabricator will need some changes for compatibility, and a lot of stuff that still says "libphutil" or "phutil" may eventually want to say "arcanist"), and some stuff (like xhpast) is probably straight-up broken right now and needs some tweaking, but I don't anticipate any major issues here. There was never anything particularly magical about libphutil as a separate standalone library.

Test Plan: Ran `arc`, it gets about as far as it did before.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19688
2018-09-21 16:38:53 -07:00
epriestley
d8f660ec6f [Wilds] Move ArcanistRuntime to support/ArcanistRuntime.php
Summary:
Ref T13098. Currently, it lives in `init-script.php`. Move it to a separate file for similarity with `support/PhabricatorStartup.php`.

Two small changes here:

  - `dirname(dirname(...))` adjustments for new path.
  - Remove `memory_limit(-1)`, this is adjusted by the libphutil init script already.

Test Plan: Ran `arc`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13098

Differential Revision: https://secure.phabricator.com/D19687
2018-09-21 16:00:30 -07:00
epriestley
12f1ba1d77 Remove XHPAST from arcanist.
Summary: see corresponding commit in libphutil

Test Plan: linted and analyzed both libraries, got more sensible build behavior

Reviewers:

CC:
2011-01-09 22:13:30 -08:00
epriestley
2c235bdf38 Fix a couple of lint issues, and update to version 2 (github). 2011-01-09 15:51:04 -08:00
epriestley
2e73916fa2 Initial commit. 2011-01-09 15:22:25 -08:00