enhance contrib section for gem handling #455
Conversation
|
|
||
| bundle install |
There was a problem hiding this comment.
I'd keep this as the first suggestion and then the shorter version to install a more minimal install.
There was a problem hiding this comment.
I had it in, in the first version of this PR. A user on slack suggested to remove it because people tend to only read until they find something matching. That's why I dropped it and replaced it with our custom version entirely.
There was a problem hiding this comment.
I'd say let them install the full version by default and consider the partial installs as optional/advanced.
There was a problem hiding this comment.
the TL;DR version
bundle install --path .vendor/ --without development --without system_tests --without release; bundle update; bundle cleanis very important and should be the default in this document
let them install the full version by default
clear no from my side
users may not know bundler and that it should be called with --path .vendor/ (happend to me) and end up polluting their system and upgrading things they don't want to upgrade.
also it can be frustating for a user. a user comes to contribute to a project, often people even don't know what testing is. if you have a user which is willing to test and then end up with a pulluted system and also get error message after error message (the more you install, the more can fail) this can be frustrating and fear them away.
There was a problem hiding this comment.
users may not know bundler and that it should be called with --path .vendor/ (happend to me) and end up polluting their system and upgrading things they don't want to upgrade.
That's odd because for me it installs all the gems to ~/.gem and it doesn't touch the system. Which OS are you on?
There was a problem hiding this comment.
@ekohl that's exactly what c33s and I mean. It updates the global gems that are used for all projects executed by the user. To avoid this I install all gems into $projectdir/.vendor
There was a problem hiding this comment.
I wouldn't say ~/.gem are global gems. I'd call them user gems. I also haven't had issues with this. There are multiple versions and bundler picks the correct versions according to the lockfile. I will admit I only use gems within bundler.
There was a problem hiding this comment.
@ekohl
~/.gem is global, ./.gem is local :)
in composer (php package installer) they have a better approach, it is the other way round. if you run composer install the dependencies gets installed in ./vendor i have to specify --global to add a lib to my global vendors ~/.composer.
if a user has some stuff for the daily needs installed and only because of running tests for some app, it comes to conflicts.
if it is ok for you, is still can be troublesome for other persons. installing it locally ./.gem or ./.vendor is safe for everyone.
also installing every dependency can lead to problems on some systems. see github-changelog-generator/github-changelog-generator#631 voxpupuli/puppet-php#432 (comment)
we should install the minimum needed to allow easy testing. interested people read further and will install the advanced setup.
maybe we should phase it:
quickstart testing
bundle install --path .vendor/ --without development --without system_tests --without release; bundle update; bundle clean
advanced testing
longer text & info about testing.
if you want to test x then...
y is installed for ...
There was a problem hiding this comment.
@c33s I thought /usr/lib was global, ~/.gem is user and ./.gem is local, but that might just be the sysadmin in me :)
I like the quick start, but I wouldn't include bundle update and bundle clean on the same line. On a fresh install I'd assume they're not needed. Maybe an update section just below it before we get to advanced testing?
There was a problem hiding this comment.
@ekohl well you are right, all in all it is just a perspective or a wording thing.
we have three locations to install to /usr/lib, ~/.gem and ./.gem you can name them "global-global", "global" and "local" or "global", "user-local" and "local"
the main intention for me is not to pollute the users gems which can have specific versions of r10k or puppet installed. from my point of view the testing env should not, or even must not interfere with the users production env. i assume the users prod env as /usr/lib and ~/.gem.
can't say something about bundle update and bundle clean.
| If you also want to run acceptance tests: | ||
|
|
||
| ```sh | ||
| bundle install --path .vendor/ --without development --with system_tests --without release; |
No description provided.