<div dir="ltr"><div><div><div><div><div><div><div>Hi Utkarsh,<br><br></div>Good point.<br><br></div>Disabling import using vtkConfig is not a good idea for the reason you mentioned.<br><br></div>That said, I still like the idea of implementing lazy loading by default and having vtkConfig to disable it.<br><br>>  currently be easily provided by factory or other singletons in VTK library itself that control the default render window created<br><br></div>Good point.</div><div><br></div><div>Would it roughly work like this:<br><br></div>  from vtk import vtkSomeFactory<br>  vtkSomeFactory.SetDefaultClass("vtkNameOfSomeClass")<br><br></div>or like this:<br><br>  from vtkmodules import vtkSomeFactory<br>  vtkSomeFactory.SetDefaultClass("vtkNameOfSomeClass")<br><br></div>  import vtk<br><div><div><div><br></div><div><br></div><div>Based on the proposed implementation for vtk.py [1], looks like the second case is correct.</div><div><br></div><div><br></div><div>[1] <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/3674/diffs#95bcbb4f764974495db2df50144d2e041a3373f3">https://gitlab.kitware.com/vtk/vtk/merge_requests/3674/diffs#95bcbb4f764974495db2df50144d2e041a3373f3</a><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 15, 2017 at 8:55 AM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">JC,<br>
<br>
I am not a huge fan of this option since the `vtk`package will not<br>
provide a consistent interface based on how the package was imported.<br>
It will make it impossible to write scripts that use `import vtk` and<br>
work reliably. e..g say I have a module (outside VTK) that relies on<br>
`import vtk` to have all necessary symbols. Now my script will fail,<br>
if some other module that the user imported before importing my module<br>
changed the nature of the `vtk` package. Thus, the only way to write<br>
reliable scripts is to import internal modules as needed, and that<br>
defeats the purpose.<br>
<br>
The future config you envision could currently be easily provided by<br>
factory or other singletons in VTK library itself that control the<br>
default render window created, for example, and should indeed be<br>
supported there since it's useful for C++ users of VTK too.<br>
<span class="HOEnZb"><font color="#888888"><br>
Utkarsh<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Dec 15, 2017 at 12:04 AM, Jean-Christophe Fillion-Robin<br>
<<a href="mailto:jchris.fillionr@kitware.com">jchris.fillionr@kitware.com</a>> wrote:<br>
> Hi Utkarsh,<br>
><br>
> I would prefer to have a more generic way of configuring the import<br>
> behavior.<br>
><br>
> The idea would be to have two top-level packages:  vtk and vtkConfig<br>
><br>
> To skip  loading of all module, you would do:<br>
><br>
> -------------------<br>
> import vtkConfig<br>
> vtkConfig.VTK_MODULE_IMPORT = vtkConfig.EXPLICIT   #  Default would be<br>
> vtkConfig.ALL.  Later we could also have vtkConfig.LAZY<br>
><br>
> import vtk<br>
> -------------------<br>
><br>
> This would allow to keep things coherent for our user. Naming the package<br>
> "vtkmodules" seem unconventional.<br>
><br>
> It would also have the advantage of support addition of new option.<br>
><br>
> For example:<br>
><br>
> vtkConfig.RENDERING_METHOD = vtkConfig.OFFSCREEN  #  or vtkConfig.MESA, ....<br>
><br>
> Jc<br>
><br>
><br>
> On Tue, Dec 12, 2017 at 4:55 PM, Utkarsh Ayachit<br>
> <<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<br>
>><br>
>> On Tue, Dec 12, 2017 at 3:18 PM, Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>><br>
>> wrote:<br>
>> > On Tue, Dec 12, 2017 at 15:06:15 -0500, Prabhu Ramachandran wrote:<br>
>> >> Would `vtkm` be a shorter name rather than `vtkmodules`?<br>
>> ><br>
>> > `vtkm` is a different project already (though I don't know of its status<br>
>> > with Python wrapping outside of the VTK filters which use it).<br>
>><br>
>> Yea, alas `vtkm` won't be a good option.<br>
>> ______________________________<wbr>_________________<br>
>> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
>><br>
>> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>vtk-developers</a><br>
>><br>
>> Follow this link to subscribe/unsubscribe:<br>
>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/vtk-<wbr>developers</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> <a href="tel:%2B1%20919%20869%208849" value="+19198698849">+1 919 869 8849</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+1 919 869 8849<br></div>
</div>