Re: [Taler] Taler dev setup

[Lukas Großberger]

Thanks for your input, Christian.

>> 2.2) How do you deal with submodule dependencies when you
>> are actually developing on the submodule? I now symlinked to
>> web-common in place of the original submodule, which seems
>> hacky.
>
> We (currently) use Git submodules. If you run
>
> $ git submodule init
> $ git submodule update --remote
>
> the web-common should be cloned properly as well.
Apologies, I didn't make myself clear enough. I am talking about the
case when I'm developing on web-common and try to integrate / test these
changes in repos that depend on web-common. The standard procedure
described by you above and in the documentation gets me the current
master of web-common but not the feature branch that I'm interested in
testing with the dependent repos. So far I've only read about
(temporally) configuring a target branch into .gitmodules which is under
version control and therefore not ideal to manipulate temporally for a
local setup. Also, if one doesn't additionally want to change the
submodule url to a local directory path, one always needs to push the
relevant changes to the web-common feature branch and updating the
submodule again, before changes can be tested jointly. To work around
this, I symlinked the local web-common repo to the submodule path in the
dependent repo, trying not to commit that type change of the web-common
sub directory to git. Thereby I immediately have the changes in
web-common in the dependent repo to test with.

All the best, Lukas


On 04.05.19 20:38, Christian Grothoff wrote:
> On 5/3/19 8:42 AM, Lukas Großberger wrote:
>> Dear Taler community,
>>
>> I had great fun working on the web-common, auditor and landing repo.
>> With these it's fairly straight forward to run / build them stand alone,
>> locally. Especially with the extended README instructions that you
>> provided along the way, thanks again.
>>
>> With other more elaborate setup procedures, e.g. for the donations or
>> blog repo, it seems like the setup is dependent on a fairly specific
>> environment (e.g. doesn't work if the Python environment happens to be
>> an Anaconda environment). These are fair assumptions made, I'd say.
>> Especially for a service that is not meant to be run on a very
>> heterogeneous group of machines. I'm now just wondering about your best
>> practices for setting up a Taler development environment.
>> 1) Is it feasible and reasonable to set up every repo stand alone? This
>> would make it easier for people starting out to contribute to Taler. If
>> so, can we jointly create documentation for each repo on how to do this?
> 
> Sure, more documentation wouldn't be wrong. Documenting the setup for
> some of the repos has not been a priority as they are mostly intended
> for the demonstration (blog and donations in particular are in this
> category).
> 
>> 2.1) How do you, core developers, set up your local development
>> environment? Do you have one dedicated machine where you do the system
>> wide setup and nothing else, a VM, possibly a dockerized version?
> 
> Everything we do should be visible in the deployment.git, there you have
> (hopefully) all the configuration files needed to reproduce the setup.
> And no, we're just running as normal users on a Debian GNU/Linux setup,
> no VM, no docker.
> 
>> 2.2) How do you deal with submodule dependencies when you are actually
>> developing on the submodule? I now symlinked to web-common in place of
>> the original submodule, which seems hacky.
> 
> We (currently) use Git submodules. If you run
> 
> $ git submodule init
> $ git submodule update --remote
> 
> the web-common should be cloned properly as well. Florian recently
> considered moving to something different (but I'm not sure he intended
> it for the web-common case), but for now it's just Git submodules.
> 
>> I'm looking forward to diving in deeper into all the Taler components :)
> 
> Great! Happy hacking!
> 
> -Chrsitian
>