Clarify steps set up development easyblocks (and framework)

[JackPerdue]

I followed the steps on this page as I tried to update impi.py:

https://github.com/hpcugent/easybuild/wiki/Setting-up-your-own-easyblocks-repository

and found that the only way my impy.py would be executed (being later in the PYTHONPATH), was to rename the installed EB's version of impy.py (and .pyc) to *.disabled.

It seemed to always include EB's version before mine otherwise.

I'm similarly curious about how to set up a development environment for the framework. Can I use the same trick and just create easybuild/toolchain? I might have some changes to intelmpi.py to test.

configs were easy with the robot environment variable. But I have changes for blocks and framework I'd like to test and merge but my previous development model was rather crude (overwriting the default installation with my updates... then trying to remember where all those updates were). I'm just trying to understand the best approach.

[boegel]

I just noticed that was left unanswered, my apologies.

Part of your questions were already answered via the other issue you created (https://github.com/hpcugent/easybuild-easyblocks/issues/455), so let's continue that discussion there.

W.r.t. the development environment for the framework, take a look at the install-EasyBuild-develop.sh script available in easybuild/scripts in the easybuild-framework repository (https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/scripts/install-EasyBuild-develop.sh). It will set up a working environment with the develop branches of the different repositories to play around in, based on your forks on GitHub, and will even install a module that you can load to set up your environment ($PATH and $PYTHONPATH).

That should help you in playing around with stuff, and preparing contributions.

Word of warning: don't trust this develop setup to do production installations, although the develop branches are pretty stable (we test & review things carefully before we merge something in, and the framework unit tests do a great job of avoiding unintended behaviour changes).

Let us know if this answers the questions you had, so we can close this issue rather than leaving it dangling open.