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

images in package descriptions not imported/ rendering #77

Open
slumnitz opened this issue Jul 26, 2019 · 5 comments
Open

images in package descriptions not imported/ rendering #77

slumnitz opened this issue Jul 26, 2019 · 5 comments
Assignees
Labels

Comments

@slumnitz
Copy link
Member

I noticed that most packages have a static image in their README.md which is not rendered in the notebook book. I suppose due to the images not being imported in this repo/ and the image links being broken since the hard-coded image path changed.

It seems like GitHub markdown does not really support absolute image paths, so maybe it is possible to pull the images in this repo as well?

@slumnitz slumnitz changed the title images in not imported/ rendering images in package descriptions not imported/ rendering Jul 26, 2019
@darribas
Copy link
Member

Good catch! Yes, I think this would have to be caught and processed on write_package_intro:

https://github.com/pysal/notebooks/blob/master/lib/build.py#L216

Maybe that method should also include a check for .png in the text and, if found, grab them?

@sjsrey
Copy link
Member

sjsrey commented Jul 26, 2019

Since we are likely to uncover other issues that should be standardized across subpackages, we should document these here.

@knaaptime
Copy link
Member

+1 i was going to say something similar since we dont have any conventions currently as to where those images are stored. Would make things easy if we can just grab the docs/images (or whatever) dir from each package

@darribas
Copy link
Member

Yes, it might be worth sorting out those standards first and then pulling them into the notebooks project?

@sjsrey
Copy link
Member

sjsrey commented Jul 26, 2019

There are likely to be other, similar, issues that we probably want to document in the su

Yes, it might be worth sorting out those standards first and then pulling them into the notebooks project?

I think so. We use the notebooks project to smooth the rough edges and discover best practices. Then we codify in the submodule instructions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants