43 installation instructions #50
Conversation
| 1. Either clone the repository or download a release and place it anywhere you | ||
| like. | ||
|
|
||
| 2. Install dependencies with Composer: | ||
|
|
There was a problem hiding this comment.
Here I would add something like: "Change to the directory where you clone or download the release and then run:"
|
|
||
| If you're about to use Dorgflow in the context of a composer driver Drupal project, where you e.g. want to use version 8.x-3.1 of a particular module for staging and the production server, you may easily run into trouble setting up your environment for drupal.org contributions controlled by dorgflow. For those of you there is a composer plugin available which helps you manage those environments: https://packagist.org/packages/lakedrops/dorgflow | ||
| If you're about to use Dorgflow in the context of a composer driver Drupal |
| staging and the production server, you may easily run into trouble setting up | ||
| your environment for drupal.org contributions controlled by dorgflow. For those | ||
| of you there is a composer plugin available which helps you manage those | ||
| environments: https://packagist.org/packages/lakedrops/dorgflow |
There was a problem hiding this comment.
I think this section is still confusing. Most every D8 project these days is "composer driven". This implies that if you use composer then you should use the lakedrops/dorgflow package, which isn't the case. I haven't run into "trouble setting up your environment" and don't even know what this refers to.
There was a problem hiding this comment.
I agree, but the problem is that I don't really know what it means myself, as I didn't write it.
I think that plugin lets you easily have Composer install the contrib modules you specify as git clones rather than just flat files.
But that's not my workflow at all. I usually just move out the composer-managed contrib module folder, symlink in a git clone from my sandbox folder, and then make the changes I want, and then when I'm done, move the composer-managed folder back in! Probably not ideal, but it means I don't have to fight with Composer.
There was a problem hiding this comment.
I too agree. Maybe it is time to reach out to the maintainers of the lakedrops/dorgflow project to ask what advantage there is to using their project verses globally installing joachim-n/dorgflow.
There was a problem hiding this comment.
I emailed @jurgenhaas to see if he would help us out on finishing this pull request with some advice since he is the maintainer of the lakedrops/dorgflow composer package. It is hosted on a private Gitlab instance so that is why I emailed him. He does have a Github account. Hopefully we will hear from him soon.
There was a problem hiding this comment.
Just responded to the issue in this comment
There was a problem hiding this comment.
@jurgenhaas Thanks for updating the documentation for your project lakedrops/dorgflow.
Can you please comment on the proposed section to be added to this project joachim-n/dorgflow that talks about how to use your project (Lines 28 - 33 of the README.md)?
Does this sound correct to you? Should it be worded differently? Should this project use a modified version of the new documentation you added to your project? Or should this project just add a link to your projects documentation?
There was a problem hiding this comment.
Those lines (28-33) sound about right. Just wondering if there is any other use case around or if not everyone developing Drupal components will be addressed by exactly that scenario.
In terms of how to get users to understand lakedrops/dorgflow, I think it's best to link to that project in order to make sure that future updates will apply automatically. You don't want to update this project here every single time there is going to be an update on the remote project.
Fix for #43.