<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 10, 2016 at 3:21 PM, Isaac Bennetch <span dir="ltr"><<a href="mailto:bennetch@gmail.com" target="_blank">bennetch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><div class="h5"><br>
On 2/10/16 2:40 AM, Michal Čihař wrote:<br>
> Hi<br>
><br>
> Dne 9.2.2016 v 21:25 Dan Ungureanu napsal(a):<br>
>> The first time I sent my proposal for Google Summer of Code 2015 I tried<br>
>> finding libraries that would fit phpMyAdmin. Because I found none I<br>
>> thought that I could create a library on my own hoping that others (not<br>
>> only phpMyAdmin) would benefit from it and will help developing it<br>
>> (testing, sending bug reports, etc). I talked with Marc and he seemed to<br>
>> be fine with this.<br>
>><br>
>> After the summer ended, I was planning on talking with Marc to transfer<br>
>> the library to phpMyAdmin, but I did not get to do that. Hopefully, we<br>
>> can do this soon.<br>
><br>
> Okay, let's process with this (see mail I've sent you privately).<br>
><br>
>> In my opinion, the best option would be to manage dependencies with<br>
>> Composer, but I proposed this in the past and people did not consider<br>
>> this a very good idea. Anyway, I still believe that keeping the library<br>
>> in a different repository is the best way because:<br>
>>  - it makes bug fixing easier; no need to merge upstream, older versions<br>
>> of phpMyAdmin may be easier to patch, etc;<br>
>>  - the changes to the library don't pollute the change log of phpMyAdmin;<br>
>>  - it is designed as a "module" to phpMyAdmin and the logic related to<br>
>> SQL queries is separated;<br>
>>  - maybe at some time in the future the library will also be used in<br>
>> other projects.<br>
><br>
> I still want the library to be kept in separate repository. I just want<br>
> to embed that one inside phpmyadmin one as a submodule, see<br>
> <a href="https://git-scm.com/docs/git-submodule" rel="noreferrer" target="_blank">https://git-scm.com/docs/git-submodule</a><br>
<br>
</div></div>On the surface, this seems like quite a good solution, but from what I<br>
recall (and a quick look at that page confirms my memory), it is a bit<br>
awkward to work with submodules. For instance, one has to manually<br>
update/sync to the submodule and it seems easy to get out of sync. I've<br>
never worked with submodules and I definitely might be wrong about this,<br>
but the documentation makes this process sound awkward.<br>
<span class=""><br>
> I'm not sure about using Composer - people still expect to find complete<br>
> tarball on our website...<br>
<br>
</span>I agree that we should distribute the complete tarball and not require<br>
using Composer for this.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Developers mailing list<br>
<a href="mailto:Developers@phpmyadmin.net">Developers@phpmyadmin.net</a><br>
<a href="https://lists.phpmyadmin.net/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.phpmyadmin.net/mailman/listinfo/developers</a></div></div></blockquote><div><br></div><div>Hello,</div><div><br></div><div>As far as I know, submodules must be pulled manually and this might confuse people.</div><div><br></div><div>The script that generates the release can be modified to install Composer dependencies first and then create the tarball.</div><div><br></div><div>Best regards,</div><div>Dan Ungureanu</div></div></div></div>