<div dir="ltr"><div><div dir="auto">hi sabry,</div><div dir="auto"><br></div><div dir="auto">i was planning to give your new 3.7 a shot, i.e. start rebuilding our derived modules for NLPL (rather than try to reatroactively fix based XZ support based on 3.5). however, it seems ‘virtualenv’ is not available in python3/<a href="http://3.7.0.">3.7.0.</a> is that something you could still add for us?</div><div dir="auto"><br></div><div>oe</div><div><br></div></div></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, 15 Jan 2019 at 09:56 Sabry Razick via RT <<a href="mailto:hpc-drift@usit.uio.no" target="_blank">hpc-drift@usit.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
Will the module "module load Python/3.5.2-foss-2016b" work for you all you want to recompile a new one ?<br>
<br>
Regards,<br>
Sabry.<br>
<br>
On 2019-01-08 14:34:40, sabryr wrote:<br>
> Hi,<br>
> <br>
> On 2019-01-08 13:35:25, oe wrote:<br>
> > many thanks for the quick follow-up, sabry!<br>
> <br>
> You are welcome<br>
> <br>
> > would there be a relatively easy way of retroactively fixing the<br>
> > 3.5.0<br>
> > module?<br>
> <br>
> No, due to the policy that installed modules will not change. As I<br>
> would have to recompile,can not guarantee the change will be only the<br>
> lzima,thus potentially effect others. But I can install another 3.5.<br>
> module for you, if miner version is not a problem.<br>
> <br>
> For example is following module usable (a secret module we have)<br>
> <br>
> module load Python/3.5.2-foss-2016b<br>
> <br>
> If not, we can install similar semi-secret module.<br>
> <br>
> i am asking because in the NLPL context we have produced at<br>
> > least half a dozen python modules that are derived from the base<br>
> > ‘python3/3.5.0’ module. here, derivative means creating a virtual<br>
> > environment, installing one or more add-on packages, and tweaking<br>
> > PYTHONPATH such that several such derivative modules can be combined.<br>
> > we have adopted this path for NLPL, for better modularity,<br>
> > interoperability, and uniformity between Abel and Taito. some<br>
> > additional background on this approach is on the NLPL wiki:<br>
> ><br>
> > <a href="http://wiki.nlpl.eu/index.php/Infrastructure/software/python" rel="noreferrer" target="_blank">http://wiki.nlpl.eu/index.php/Infrastructure/software/python</a><br>
> <br>
> As the workload will be less on our end, I will try to help on this.<br>
> <br>
> <br>
> > switching to a different base module (e.g. from 3.5.0 to 3.7.0) would<br>
> > require rebuilding all of these derivative modules (hence is not<br>
> > something i would not do light-heartedly :-). but see below ...<br>
> ><br>
> > —more generally, we have been meaning to start a fresh batch of<br>
> > derivative modules based on 3.6 or even 3.7. to start down this<br>
> > route, it would be important to agree on which characteristics the<br>
> > base python module should have. (unlike the older 3.5.0<br>
> > installation)<br>
> > i see that your new 3.7.0 is minimal, i.e. does not (yet) include any<br>
> > add-on components.<br>
> <br>
> That is correct. The future plan is to provide basic python and<br>
> another module called "python-modules". There is no PYTHONPATH set in<br>
> this module either and highly customizable.<br>
> <br>
> in principle, i think this is right, and all<br>
> > add-ons should arguably be provisioned as separate modules. what<br>
> > about NumPy with MKL support, however? that was compiled into the<br>
> > 3.5.0 installation and is something i suspect many users might want.<br>
> > or maybe the default OpenBLAS back-end for NumPy is just as good (on<br>
> > average), and we can make do with standard, pre-compiled NumPy<br>
> > wheels?<br>
> > if so, is there a particular reason you opted to build the new 3.7.0<br>
> > with the Intel tool chain?<br>
> <br>
> Latest MKL, older OpenBLAS, (latest blas and Atlas soon) available<br>
> when you load the " module load python3/3.7.0", but you must compile<br>
> numpy (not from wheel) to use it.<br>
> <br>
> $ module load python3/3.7.0<br>
> $ echo $CPATH | grep mkl --color=always<br>
> <br>
> /cluster/software/VERSIONS/intel-<br>
> 2019.0/compilers_and_libraries_2019.0.117/linux/mkl/include/<br>
> /cluster/software/VERSIONS/intel-<br>
> 2019.0/compilers_and_libraries_2019.0.117/linux/mkl/include/fftw:<br>
> <br>
> <br>
> > in the NLPL context, we have been tossing around some of these<br>
> > high-level design questions for a little while now, and i am hoping<br>
> > to<br>
> > tap into your broader experience with maintaining modules on Abel<br>
> > here. would it make sense to discuss some of the more general<br>
> > questions over a cup of coffee sometime this week? anyone else in<br>
> > your group with strong opinions about python modules?<br>
> <br>
> Yes we could discuss this, I do not think there are strong opinions,<br>
> but I could ask permission from Jon if needed . Only thing is once<br>
> installed modules are (almost) newer changed.<br>
> <br>
> <br>
> Regards,<br>
> Sabry<br>
> ><br>
> > with thanks in advance, oe<br>
> ><br>
> > On Tue, Jan 8, 2019 at 11:31 AM Sabry Razick via RT<br>
> > <<a href="mailto:hpc-drift@usit.uio.no" target="_blank">hpc-drift@usit.uio.no</a>> wrote:<br>
> > ><br>
> > > On 2019-01-07 23:20:24, oe wrote:<br>
> > > > colleagues,<br>
> > > ><br>
> > > > using the default ‘python3’ module on Abel, i am running into the<br>
> > > > following import error (required by a third-party component):<br>
> > > ><br>
> > > > [oe@login-0-0 ~]$ module purge; module load python3/3.5.0<br>
> > > > [oe@login-0-0 ~]$ type -all python3<br>
> > > > python3 is /cluster/software/VERSIONS/python3-3.5.0/bin/python3<br>
> > > > [oe@login-0-0 ~]$ python3 -c "import lzma;"<br>
> > > > Traceback (most recent call last):<br>
> > > > File "<string>", line 1, in <module><br>
> > > > File "/cluster/software/VERSIONS/python3-<br>
> > > > 3.5.0/lib/python3.5/lzma.py",<br>
> > > > line 26, in <module><br>
> > > > from _lzma import *<br>
> > > > ImportError: No module named '_lzma'<br>
> > > ><br>
> > > > for all i can tell, there are no RHEL lzma packaged installed,<br>
> > > > but<br>
> > > > there is a separate module ‘xz/5.2.2’. i wonder whether my<br>
> > > > import<br>
> > > > error could just mean that no lzma (aka xz) headers and libraries<br>
> > > > were<br>
> > > > visible when the python3 installation was compiled?<br>
> > > ><br>
> > > > with thanks in advance, oe<br>
> > > ><br>
> > ><br>
> > > Hi,<br>
> > > Your observation is correct. I have fixed this in the latest<br>
> > > version (did not fix the old).<br>
> > ><br>
> > > -bash-4.1$ module purge<br>
> > > -bash-4.1$ module load python3/3.7.0<br>
> > > -bash-4.1$ python3 -c "import lzma;"<br>
> > > -bash-4.1$ python3 -c "import lzma;print(lzma.__file__)"<br>
> > > /cluster/software/VERSIONS/python3-3.7.0/lib/python3.7/lzma.py<br>
> > ><br>
> > ><br>
> > > Regards,<br>
> > > Sabry<br>
> > ><br>
<br>
</blockquote></div></div>