New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace deprecated pr.create_job
in first_steps.ipynb
#1517
base: main
Are you sure you want to change the base?
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
To be honest it's a horrible idea to show an example to heat up Aluminium to 1,000 K... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I am assuming the replacing pr.create for structures will be done elsewhere (if planned) as it is not in the PL title, and it's good to see the warnings about it now.
"source": [ | ||
"from pyiron import Project" | ||
"from pyiron_atomistics import Project" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are testing this from the pyiron
repo, I would stick to from pyiron import Project
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm I see your point, but pyiron
takes so much more time that it might be a bit discouraging to see this in the very first line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but this is the only test-space to check that the from pyiron import
is working correctly! Maybe we have to make the lookup faster if it is just too annoying? Or is it because you also have all the other pyiron modules installed which are not loaded in a nice way (especially contrib...). I mean if only
conda create --name pyiron pyiron
was used it should essentially only find and load pyiton_atomistics
at a moderate overhead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but this is the only test-space to check that the
from pyiron import
is working correctly!
Would your concern be addressed if I create an example notebook that uses e.g. both pyiron_atomistics
and pyiron_continuum
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'm with Niklas here -- this is basically the only place that we might reasonably from pyiron import...
and then expect that to be providing us with sub module support (atomistics, continuum, etc). So if that's something we want to provide, IMO this is the right place to test it. The fact it's painfully slow is related, but a separate issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am in favor of leaving it from pyiron
here. However, it might be reasonable to use the notebooks from the pyiron_atomistics
repo for the education on the website.
Furthermore, we probably should raise an issue for the slow import.
Some solution could be:
- not import but only find other
pyiron_modules
than pyiron_atomistics on import of pyiron and import those upon access. - provide a module scoped list (dict? ) which is used to omit the finding in the first place, i.e. a list like
['contrib', 'gui', ... ]
which is used for autocompletion and to extend this to the corresponding pyiron_module. If a not listed access pyiron.some_mod is performed try toimport pyiron_some_mod
and use this. - stop treating pyiron as drop in replacement of pyiron_atomistics and actually use pyiron.atomistics (probably together with one of the first). Breaks backwards compatibility, though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am in favor of leaving it
from pyiron
here. However, it might be reasonable to use the notebooks from thepyiron_atomistics
repo for the education on the website.
ok that means I should copy this notebook to pyiron_atomistics
and create an integration tests folder where we'd have essentially the same content with from pyiron import Project
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not check the exact content, but aren't the notebooks here exactly such copies from pyiron_atomistics with the from pyiron
to from pyiron_atomistics
change? It is a not so nice setup, since near duplication, i.e. please apply the same changes over in pyiron_atomistics 😇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I really meant for the purpose of displaying on the webpage. Right now, the tutorial is from this repo, while you claim it to be much faster if we use the notebooks from pyiron_atomistics for the webpage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not check the exact content, but aren't the notebooks here exactly such copies from pyiron_atomistics with the
from pyiron
tofrom pyiron_atomistics
change?
AHA!! I didn't know that it existed TWICE!
And I really meant for the purpose of displaying on the webpage.
I'm not really sure if I understand what you are referring to. Do I understand it correctly:
- We keep
from pyiron import Project
in this repo - On the website we use the version from
pyiron_atomistics
, i.e. the same notebook withfrom pyiron_atomistics import Project
?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Merge main
Mentioned in this issue