put easyblocks in easybuild.easyblocks namespace #87
Conversation
ghost
assigned 
|
Just as a side-note: we're considering this change because then others are free to use a different scheme for organizing their easyblocks, just as long as they also use the easybuild.easyblocks namespace we're aiming at. |
|
I'm trying to come up with a straightforward solution here, but there doesn't seem to be a quick answer: |
|
Ok, it is simpler then thought: __path__.extend([os.path.join(__path__[0],chr(y)) for y in range(ord('a'),ord('z')+1) + [ord('0')] ])but learnt me some great python hacks on the way. |
|
good point; now for generality I suggest the following: __path__.extend([os.path.join(__path__[0],chr(y)) for y in range(ord('a'),ord('z')+1) + range(ord('0'),ord('9')+1) + [ord('_')] ])ie. the funny underscore directory will hold the more funny things in it, and all dirs are mapping nicely to directory: enjoy, |
|
@fgeorgatos: We use the @JensTimmerman: Nice solution after all the screwing around we did this afternoon. :D |
|
Hi there, indeed this is better practice: "use the 0 subdirectory as a catch all" and I didn't realize that the python oneliner I supplied isn't up to the task: only Jens solution gets both the elegance and the result ;-) |
|
Please review pull request. |
| @@ -22,3 +22,8 @@ | |||
| # You should have received a copy of the GNU General Public License | |||
| # along with EasyBuild. If not, see <http://www.gnu.org/licenses/>. | |||
| ## | |||
| import os | |||
| from pkgutil import extend_path | |||
|
|
|||
There was a problem hiding this comment.
You really need to add documentation here, describing what this does, and how it works.
Maybe also information on how to change this if you're using a different directory structure to organize the easyblocks in.
Is there a way to make this more generic, so that it works no matter what the easyblocks subdirs are? E.g. use os.listdir, and extend _path_ with that?
There was a problem hiding this comment.
os.listdir might add a big overhead.
There is no need to be generic here, since we know what we are doing, other people using a different scheme will also know what it is.
I suspect people will want to either use one directory, or adopt our a-z + 0 scheme.
I'll add a short description of why we do this + an explenation to the FAQ about this.
…ce everything is in the easybuild.easyblocks namespace now
|
updated application.py + processed remarks. |
| # Extend path so python finds our easyblocks in the subdirectories where they are located | ||
| __path__.extend([os.path.join(__path__[0],chr(y)) for y in range(ord('a'),ord('z')+1) + [ord('0')] ]) | ||
| # And let python know this is not the only place to look for them, | ||
| # so we can have 2 easybuild/easyblock paths in your pythonpath, one for public, one for private easyblocks. |
There was a problem hiding this comment.
change '2' to 'multiple', I don't think this limits it to just too, you can have dozens if you want to.
We will just try to import the easyblock when none is defined, if this fails, fall back to application. Since we can't know where the easyblock is actually located, it could be anywhere in __path__ So let python figure this out.
|
Building trilinos works. |
put easyblocks in easybuild.easyblocks namespace
Currently easyblocks are in the easybuild.easyblocks.a-z namespace, let's move this all up.
We can keep the directory structure, just define them in the correct namespace.