Move automatiek to the main repo
#3750
Conversation
deivid-rodriguez
force-pushed
the
vendor_automatiek
branch
from
4c765fb
to
47b1704
Compare
|
I had this idea a few days ago here, and I believe it's the simplest thing to do. |
Currently we can't use the proper automatiek version, because the changes we need are not released. Given this is so little code, I think it's better to keep it inside the main repo.
deivid-rodriguez
force-pushed
the
vendor_automatiek
branch
from
47b1704
to
35acda1
Compare
|
Great, let's do it! |
|
This is a violation of the automatiek license — given a substantial piece of the software was copied, the license & copyright notice must accompany the copied code |
|
Given that we use the same license (MIT), and distribute that license with the code, what other actions should we take? Never heard of such an issue when talking about one of the most permissive licenses. In any case, we should definitely write a notice somewhere saying big thanks to you for the original code 🙌, since that information is no longer available in |
|
|
Oh, I think I see what you mean, let me open a PR and I'll tag you. |
Description:
Currently the process of vendoring dependencies is quite tedious because either it requires manual changes, or
automatiekneeds to be refined and tweaked constantly to accommodate new dependencies we vendor.What was the end-user or developer problem that led to this PR?
Since
automatieklives as a external gem, when we need to change it, we need to wait for a release before using it inbundler, sice our currentGemfilesetup does not support "git sourced gems". So this process is not very agile.What is your fix for the problem, implemented in this PR?
My fix is to move automatiek to the rubygems repo, since it's just one ruby file.
See segiddins/automatiek#10.
Tasks:
I will abide by the code of conduct.