Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

samwaseda
Copy link
Member

Mentioned in this issue

Copy link

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

@samwaseda
Copy link
Member Author

To be honest it's a horrible idea to show an example to heat up Aluminium to 1,000 K...

Copy link

@pkruzikova pkruzikova left a 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"
Copy link
Member

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

Copy link
Member Author

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

Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member

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 to import 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!

Copy link
Member Author

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.

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?

Copy link
Member

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 😇

Copy link
Member

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.

Copy link
Member Author

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?

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 with from pyiron_atomistics import Project?

Copy link

stale bot commented Dec 15, 2023

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.

@stale stale bot added the stale Inactive for two weeks label Dec 15, 2023
@stale stale bot removed the stale Inactive for two weeks label Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants