We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.

Separately, developing on Windows has its own complications

• I ran into some issues with windows-style vs. unix-style line endings. I think this can be resolved with a configuration but the warning messages spit out by git are confusing
• I think git on windows uses its own built-in ssh which doesn't seem to play well with the ssh-agent running on the system. Despite adding my key to the ssh-agent and confirming it's in there the git commands refuse to acknowledge it -- I think arcanist bombs if a git command results in prompting for user input which has made this difficult. I haven't yet figured out how to get this working, possibly some use of GIT_SSH_COMMAND though my initial attempts did not succeed
• xhpast is configured to run for lint/ut but there is no xhpast binary for windows systems. It looks like someone has written up a way to do this but it involves installing a compiler and compiling it x_x
  • https://secure.phabricator.com/w/community_resources/building_xhpast_on_windows/

I have a plan for a single docker container for developing extensions.
It's really a question of "what will people like", so maybe throw everything at the wall and see what sticks.

In T15011#363, @speck wrote:

We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.

Separately, developing on Windows has its own complications

We should consider a Vagrantfile in place of docker containers.

I haven't used Vagrant, however I think I am cool with any setup as long as it is:

• Run a couple commands, and done
• Works in WSL and VSCode

I would throw in though that docker-compose accomplishes nearly the same thing by coordinating the containers so it can be run by simply executing docker-compose up

Separately, developing on Windows has its own complications

• Solution to (almost) all Windows developer problems = WSL !!!!! (specifically WSL2 which is amazing)
  • Changed my life
  • Supports containers
  • Supports VSCode out of box
  • No more windows problems

In T15011#366, @avivey wrote:

I have a plan for a single docker container for developing extensions.

Good point and awesome! - We could have multiple environments depending on what you are developing

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

It is working pretty well with notifications and repository hosting both configured out of the box. My only concern with the config at the moment is that it's very much setup for development -- we would want to clearly document that it is not to be used as a starting point for a production docker-compose setup!

Any feedback would be appreciated!

In T15011#370, @willson556 wrote:

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

It is working pretty well with notifications and repository hosting both configured out of the box. My only concern with the config at the moment is that it's very much setup for development -- we would want to clearly document that it is not to be used as a starting point for a production docker-compose setup!

Any feedback would be appreciated!

@willson556 This looks pretty awesome - I am going to try it in a bit, my very first thought though is allow the http port to be configurable through an ENV var... I locally run can internal app on port 80 almost all the time, so it would be nice to be able to set an ENV Var for this to run on some other configurable port

A few things @willson556

• Untracked file in phorge source support/aphlict/server/package-lock.json

root@63c842bff39e:/srv/phorge/phorge# git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        support/aphlict/server/package-lock.json

nothing added to commit but untracked files present (use "git add" to track)

rP .arcconfig is pointing at secure.phabricator.com - Which will be fixed by D25001 I assume
Same issue in rARC .arcconfig is pointing at secure.phabricator.com - - But no revision exists yet - Made D25003

Ports
Like I mentioned T15011#372 ports should be env

Looks like this is pretty awesome overall! -

In T15011#386, @Ekubischta wrote:

A few things @willson556

• Untracked file in phorge source support/aphlict/server/package-lock.json

This is probably a result of the process for getting Aphlict up and running. The documentation for installing Aphlict instructs you to npm install ws in the support/aphlict/server/ folder but it looks since that documentation was written newer versions of node/npm will write out package-lock.json which the repository is not setup to ignore. We'll need to add that file to the .gitignore file I think.

In T15011#390, @speck wrote:

The documentation for installing Aphlict instructs you to npm install ws in the support/aphlict/server/ folder but it looks since that documentation was written newer versions of node/npm will write out package-lock.json which the repository is not setup to ignore. We'll need to add that file to the .gitignore file I think.

Another option might be to update instructions to npm install ws --no-package-lock which I believe will stop npm from generating the lock file

Although like you said .gitignore is probs the best option

Ah I wasn't aware of that option. I created D25004: Update .gitignore to account for package-lock.json if we want to update the .gitignore

@willson556: phorge-devcontainer looks awesome. I'll try it out asap. I may be able to contribute as well, I've got a bit of experience building reusable development environments.

We should consider a Vagrantfile

Also a fan of the Vagrant pattern. I'm willing to help out here.

I want to also mention on this topic... Using a pre-packaged VirtualBox image can be a straightforward distribution route, with a drawback being filesize... Perhaps Torrents could be a neat way alternative to distribute something like that, though there would be a few options including sponsored mirrors, etc... VirtualBox is a common Vagrant provider, so oftentimes it is a prerequisite anyway...

From my perspective, considering all of Linux, Windows, and MacOS equally, the most straightforward ways to get up and running cross-platform would be in order, for someone who just wants to smoothly get started contributing code and doesn't already have any of these things setup, regardless of development OS:

1. Virtualbox image
2. Vagrant
3. Docker

The tradeoffs for the VB image may be great enough to where Vagrant is preferred... Plus the auto networking configuration of Vagrant might make it more appealing and reduce documentation and support...

Definitely liking the idea of a Vagrant setup, but wanted to mention that going straight to VirtualBox is also an option, and could likely be available already to someone who has Vagrant installed

In T15011#370, @willson556 wrote:

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

So this phorge-devcontainer seems totally awesome... it looks very clean and thorough on first glance... May be able to adapt some of the provisioning script concepts for a Vagrant setup as well :)

I use PHPStorm as a primary IDE, and phorge-devcontainer seems targeted towards VSCode. VSCode is a great lighter-weight IDE and I keep it installed for quick opens... I would personally prefer to use PHPStorm since it's an option for me, and objectively an efficient platform as well. But not really opposed to a community-recommended guideline that would encourage me to use a different IDE for this project since VSCode is generally very acceptable.. But IDE flexibility seems ideal....

I might be tempted to come up with a VirtualBox with a complete dev environment and OS including phorge-devcontainer provisioning and VSCode preinstalled, where all development can take place inside the VM.. but I'm not sure how well-received or supportable that would be...

But I'd be interested in tackling the challenge of coming up with a generic provisioning pattern that would happen on vagrant up, ideally compatible with the Docker setup, and I already have an extensive toolbox to help make this happen...

@speck Any thoughts on some of this? As someone else who appreciates some of the benefits of using a complete accessible VM (e.g. via Vagrant)?

I've used both docker containers and vagrantfiles for development, though not too extensively. In my experience they're both pretty involved for something that requires multiple services running. I think vagrantfile might be a little more accessible for developers. Using docker will eventually require additional understanding of docker/docker-compose and how containers interact whereas virtual machines I think are easier to reason about. For example I think it will be very common for a developer to want to get to a command-line on the system running their phorge services. Doing so with docker requires knowing which container you want (docker container ls) and running an interactive bash (docker exec --it {id} bash). With vagrant it automatically sets up ssh (and handling keys, somehow) so you can do something like vagrant ssh and it drops you into bash on a single machine that has all services running.

I think both solutions work well and I don't feel too strongly one way or the other. Most of my bias towards vagrant is for onboarding developers with little to no experience with docker.

I think both solutions work well

I think since alot will depend on developer preference, we can just provide multiple options. The biggest issue ends up supporting the code behind the environments into the future.

So - we could have a vs-code .dockerfile environemnt, that will work for anyone using vscode (whether windows or mac, or windows with wsl)
We could also prove the Vagrantfile environment for those that want to use that.

We should just decide what our requirements are to bring these repos into Phorge and then support them (we may decide that these things all live on github and "use at own risk" - But, I feel strongly that we should provide 1 or more paths to developers that want to jump in and get to writing code...

Relevant links:

Wikimedia's dev environment is documented here: https://www.mediawiki.org/wiki/Phabricator/Local_Dev_Environment

There is a fully self-contained bitnami vm image which some people have had some luck with.

I've got a docker-compose setup working which runs mariadb and phabricator/phorge against shared/mounted phabricator/arcanist folders to allow easy local-modifications+. The readme outlines basic steps to get running. I've tried to keep it as minimal as possible while also making sure standard/default configurations are made so you can get up and running as soon as possible. Currently it's setup with php 7.4 but I'll be looking to update to 8.1 or 8.2. There are probably other minor things that I'll need to update with it as I use it more but I think this should generally work.

https://github.com/neandrake/phab-dev

Right now it doesn't work on windows but I can't figure out why. Works well on mac (probably also linux)

In T15011#6569, @20after4 wrote:

There is a fully self-contained bitnami vm image which some people have had some luck with.

This image has now disappeared from docker.io's repository. https://github.com/bitnami/containers/issues/8177 discusses the deprecation of the image at it's origin repo. It is currently unclear exactly when and why the tagged docker.io images were removed.

I would like to help in creating an account in docker.io for phorge, to publish again a similar image. It's not that difficult. But we need to use an official phorge.it email address, not a personal one.

I managed to compile xhpast on windows using llvm installed via Scoop. I also have Visual Studio C++ 19 installed which may be required (I saw some suspicious output that indicated that some include files were being pulled from that install somehow).

This does require creating a unistd.h in the same directory as the xhpast source, which I largely followed from this stackoverflow post. I made some modifications based on errors I was getting.

I did get a number of warnings about the use of the register keyword being deprecated in C++17, but these usages are from the output of bison/flex, and the warnings are probably okay to ignore ¯\_(ツ)_/¯.

This does not require bison/flex, which should be okay as the parser.y and scanner.l generated output from those files is checked-in to the repository (the .hpp and .cpp files for the parser and scanner). There's a comment about this in the .gitignore at the root of this repository. That said, I was able to produce these files using winflexbison (also installed from Scoop).

However after running those, the resulting .cpp and .hpp files were littered with Windows file-endings (they appear as ^M in git diff output). I didn't bother trying to use these though and instead just relied on the checked-in files. An editor that obeys .editorconfig can convert the line endings by opening the files and re-saving.

I've used phorge-devcontainer as well and it works great!

Additionally I have my own version of a production phorge docker compose setup that could be repurposed for a dev container: https://github.com/lectrician1/phorge_docker/tree/main