mattflaschen wrote on 2014-05-05 21:01:03 (UTC)

I filed a separate one for Windows, T280: [EPIC] Code Deploy Dashboard.

However, I think packaging it for GNU/Linux distributions is also reasonable. People have pointed out that not everyone (even in the MediaWiki community) already has or needs PHP, so an installer that simply handled this (installing command-line PHP automatically if needed) would be preferred.

scfc wrote on 2014-05-05 21:38:51 (UTC)

I wonder how big of a problem this is for an audience that is going to use Git in 100% of cases.

The problem isn't technical. If I had an unstoppable inflow of money and noone cared about the output, having dozens of developers spend time on installing/updating/debugging sounds like a good plan to burn some of it. As a volunteer my time is more scarce, so I neither write my own distribution nor my own encyclopedia.

People have pointed out that not everyone (even in the MediaWiki community) already has or needs PHP, so an installer that simply handled this (installing command-line PHP automatically if needed) would be preferred.

No, the package just needs to state which PHP version is required. Installing that is left to the distribution which has a much better track record of that.

mattflaschen wrote on 2014-05-05 22:49:32 (UTC)

scfc:

No, the package just needs to state which PHP version is required. Installing that is left to the distribution which has a much better track record of that.

Sorry, I should have been clearer. I was thinking only of the Windows installer with regards to installing PHP. And even for that, it should simply bundle (or download on demand) the installer from http://windows.php.net/ .

For GNU/Linux, etc (i.e. OSes with package managers). it should just add a dependency on PHP.

richard wrote on 2014-07-17 15:31:02 (UTC)

I'm working on the debian/ubuntu packaging. See https://github.com/lenios/phabricator. The source package builds binary packages for arcanist, libphutil and phabricator. All packages should work properly. The packages are in the debian NEW queue, and hopefully soon available.

System packages probably aren't the way to go anyway for arcanist. Arcanist uses the Conduit API in Phabricator and that can change (and break) so best practice is to use whatever version of Arcanist is associated with the version of Phabricator you're interacting with.

This (the above, that syncing) can be mostly automated and guided for our developers with how we tell them to setup their arcanist install. Essentially it's simply a git pull to somewhere in the user's path. That is all automatable through a setup script. The act of keeping things in sync could also be automated, or the user could simply run arc upgrade (which essentially just runs git pull on the right repos, see P1976).

But, for the record, arcanist (and Phabricator) are now packaged for Debian and Ubuntu. Not sure about Fedora.

I don't believe the lack of package for Fedora is a blocker for the Differential migration.

Not sure about Fedora.

No results:
http://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=phabricator
http://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=arcanist

Put this in the Differential project instead of Gerrit-Migration because it is not a migration blocker but still a (very very very low priority) request/task.

See also: T91422: Phabricator and Arcanist versions must be kept in sync because of occasional breaking api changes between phabricator versions.

In T133#1604278, @Aklapper wrote:

Not sure about Fedora.

No results:
http://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=phabricator
http://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=arcanist

There are some unofficial copr builds: https://copr.fedoraproject.org/coprs/tflink/phabricator/builds/

Using copr is basically the equivalent of downloading random .deb files from the internet. This bug is about being packaged *in* Fedora, not just *for* Fedora.

If this is not Resolved, then I would consider resolving it as Declined. We are not going to work on those packages ourselves, but also...

With Wikimedia Phabricator following upstream's master so close, chances are that git pull is going to be the most reliable way to have Arcanist up to date. With all our code contributors having Git enabled in their systems, it is also the simplest way to support them with documentation and advice.

In the strange case that this approach fails because Wikimedia Phabricator gets out of sync more often than desired, then probably the solution is to keep our own mirror of Arcanist in sync with our own installation. If we happen to get out of sync even after updating our instance almost every other week, we can expect the packages in the distros to get out of sync more frequently.

I think that belittles the work distribution packagers do. If I install a package, someone has made sure that it works, and that it works with the distribution I am using. It will receive security fixes, and if I use it in a workflow, I don't have to fear that the semantics of arcanist --help will suddenly change to mean rm -Rf ~.

AFAIK, WMF has to employ several engineers just to keep the Phabricator server up to date and yet is surprised when for example it maxes out on database connections. I don't want to have to worry on my own about whether the tools I use to get work done actually work.

I guess distribution packagers will test Arcanist against the Phabricator snapshot they are shipping in the same distribution? If this is true, would we willing to rely in those packages (both Phabricator and Arcanist) instead of pulling directly from Phabricator master as we have been doing until now?

PS: anyway, this is not my area of expertise, so I think this is the last potentially useful contribution I can make to this discussion. :)

Please correct me if i'm wrong: For every installation of phabricator you need to use that specific arcanist, as there is no compatibility intended between any two versions. So if you use phabricator.wikimedia.org, secure.phabricator.com and phabcirator.kde.org then you need 3 different copies of arcanist. Each obtained from that specific installation. When we document arcanist usage for our workflow, we should remember to explicitly mention that using a packaged arcanist or an others version is not support because upstream explicitly disclaims that they have no compatible interfaces.

Pulling from a distribution instead of directly from upstream woun't help with that as one distribution usually has multiple versions and different distributions have different versions. Only upstream can create a backwards compatibility guarantee and ensure that they keep it.

In T133#1605471, @Qgil wrote:

With all our code contributors having Git enabled in their systems, it is also the simplest way to support them with documentation and advice.

I do not believe this is a true statement. I know there are people who use github's web UI + gerrit-patch-uploader to contribute, without ever having to deal with git. But that's probably a separate bug.

In T133#1606686, @JanZerebecki wrote:

Please correct me if i'm wrong: For every installation of phabricator you need to use that specific arcanist, as there is no compatibility intended between any two versions. So if you use phabricator.wikimedia.org, secure.phabricator.com and phabcirator.kde.org then you need 3 different copies of arcanist. Each obtained from that specific installation. When we document arcanist usage for our workflow, we should remember to explicitly mention that using a packaged arcanist or an others version is not support because upstream explicitly disclaims that they have no compatible interfaces.

This is my understanding, correct @mmodell?

Pulling from a distribution instead of directly from upstream woun't help with that as one distribution usually has multiple versions and different distributions have different versions. Only upstream can create a backwards compatibility guarantee and ensure that they keep it.

Right, which is why this task is rightly closed, I still believe.

We probably need to distribute arcanist ourself, and update our fork when we update phabricator, to keep the two in sync. We could use debian packaging infrastructure to build debs that are updated with our own version of the source. But distributing and updating arcanist is really pretty straightforward - just git clone from our fork of arcanist and then periodically run arc upgrade to stay up to date.

Now that upstream has implemented a stable branch, I expect broken api compatibility to be infrequent and minimally disruptive.

I don't think creating debian packages for our version of arcanist is useful, except the chain of trust and integrity it provides. Instead I would suggest as alluded to in T613#1622313 to git tag --sign our version of the needed git repos and be done with it. Or get upstream to sign and use their tags as is.

We had arcanist / libphutil packaged via T137770

To be clear: it isn't in Debian itself, we just have Debian packages in our Wikimedia apt repo (initial use case was to enable aspects of CI integration with Differential).

See: https://www.mediawiki.org/wiki/Phabricator/Arcanist#Using_packages

Anyone is free to add that repo to their sources.list, of course, and install it that way. If you're on Debian and/or Ubuntu and don't like the git clone method, this is the next best thing (they'll be kept up to date and in sync with our Phabricator install for our own needs).