Reorganize images Meta-Issue about deprecated-bc HOT 28 CLOSED

Remember to use git mv if you're going to try and take this PR on.

I suppose git mv is not a must because images are saved by content and
reference. That is to say, if the images are already in the repo, when you
move them to another place not by git mv, git still use git mv in the
internal.

from deprecated-bc.

@HaveF - Agreed, though it's not git mv happening on the internals, just a database query that realizes that git already has the image in its database.

from deprecated-bc.

@gvwilson I add my comments here. You mentioned the img folder in #68, but I suppose, the img folder is not the proper place for storing lessons' img. At guide repo, the shell lesson images are laid in shell folder, it looks clear. Another option to handle images related with lesson is to set up a img folder under lesson's folder, like under swc-shell folder. Do you think we will have lots of images related with lessons in the future? If so, I suggest set up a img folder under correspond lessons.

from deprecated-bc.

I like the idea of setup a img directory under the lessons directory just to organization.

from deprecated-bc.

@gvwilson - Can I give you responsibility for resolving this?

from deprecated-bc.

The 'img' directory is under the root because some images are used in
multiple places, and Jekyll can move things around during compilation,
so we wanted a short, uniform path to any image from any file. Once the
current flurry of pull requests is over (end of this month?), we'll
probably take all the lesson material in the '_includes' directory and
move it into the 'lessons' directory: it was put in the former so that
people could include snippets of lessons in their bootcamp web sites,
but nobody's doing that, so we might as well get rid of the extra layer
of indirection. Once that goes away, it'll make more sense to
reorganize 'img' and/or move some of the content into the
'lessons/whatever' directories.
So, let's keep everything under 'img' for now, refer to images using
{{page.root}}/img/subdir/image.extension, and think about a more
sensible organization as part of putting all lesson material under
'lessons' in November.
Thanks,
Greg

from deprecated-bc.

@gvwilson - Thanks. As a side note, I think it's a little early to be evaluating how people are using bc, the repository has only really been alive for about 2 months.

from deprecated-bc.

@ahmadia So can we close this issue and #67?

from deprecated-bc.

@HaveF - I'm in agreement with @gvwilson here that we should stick with a flat img/ directory at the root and try to keep images there. If we hit naming conflicts or the folder starts getting unwieldy, we can think about breaking it up again, but I don't want to fall into the trap of premature namespacing.

@r-gaia-cs - Let's wait until this has come to agreement/resolution.

from deprecated-bc.

Premature optimization is the root of all evil. I suppose this issue does not affect too much to this repo. Maybe we can low the priority of this issue, do it in the future, and git mv is very easy to use when we find this is a real problem.

from deprecated-bc.

Finally, I fully understand @gvwilson 's idea. I agree with him. Sorry for my addle head 😄

from deprecated-bc.

I send a PR for organize images under swc-shell. But still puzzled by ipynb things.

In this ipynb file, the image are needed under files dir, if we move all images to img\lessons\swc-shell, the ipynb file can not easily used by copying swc-shell dir directly. Does the instructor need build the repo by jekyll and copy _site dir when using ipynb lessons?

from deprecated-bc.

The IPython notebooks have a frustrating requirement for the location of images that are locally served. This is a serious issue that needs a little more discussion. Thanks for bringing it up.

from deprecated-bc.

Looks like IPEP 16 will resolve the IPython notebook directory issue in the next IPython release (multidirectory support just landed in master.

Any thoughts on how we should deal with this before then? Keep IPython notebook images where they are until then seems the easiest to me.

from deprecated-bc.

On 2013-10-23 1:09 PM, Aron Ahmadia wrote:

Looks like IPEP 16
https://github.com/ipython/ipython/wiki/IPEP-16%3A-Notebook-multi-directory-dashboard-and-URL-mapping
will resolve the IPython notebook directory issue in the next IPython
release (multidirectory support just landed in master.

Any thoughts on how we should deal with this before then? Keep IPython
notebook images where they are until then seems the easiest to me.

Agreed.

from deprecated-bc.

Then, should we need to reconsider this issue?
Separating images for html and ipynb? If so, it would be hard to reuse html's images for ipynb file.

from deprecated-bc.

A real scene about this:

the web file need the image (absolute_relative_path.png), and the ipnb file also need the previous image.

from deprecated-bc.

@HaveF - Thanks for keeping the discussion going on this. The idea is to duplicate the image to the ipynb directory when it's needed. When the new IPython release has had a chance to make it into our package managers (Anaconda and Canopy), we can go through and delete the duplicates. We just need to be a little careful until then.

Somebody will need to play with the multidirectory support in IPython's master branch to make sure this is all working, but let's give it a couple of weeks to settle down a bit (unless you really want to touch brand new code).

from deprecated-bc.

@ahmadia ok, duplication is a reasonable choic. I need make some changes on #100

from deprecated-bc.

Awesome. Thanks for staying on top of this @HaveF!

from deprecated-bc.

On Wed, Nov 06, 2013 at 07:00:46AM -0800, Aron Ahmadia wrote:

The idea is to duplicate…

Noooooooo!

When the new IPython release has had a chance to make it into our
package managers (Anaconda and Canopy), we can go through and delete
the duplicates.

Oh, ok then :).

from deprecated-bc.

Quick question: would soft-linking be a viable solution?

from deprecated-bc.

On Thu, Nov 07, 2013 at 02:20:03AM -0800, Steven Koenig wrote:

Quick question: would soft-linking be a viable solution?

I think the lack of symlink support on MS Windows [1,2,3] might be a
problem there. I think for the short timespan that we expect to have
copies around, actual copies are probably better. Alternatively, we
could automatically replace symlinks with copies during our “build a
per-boot-camp branch” step 4, which is still floating in the ether.

from deprecated-bc.

@HaveF - Do you need any help from us on this?

from deprecated-bc.

😄 What I need to do on this topic?
It seems we already come to a conclusion that keeps a copy of image for web page and ipynb.

from deprecated-bc.

Okay, I have been having a hard time tracking this. Are the broken links all resolved?

from deprecated-bc.

The broken links are managed by make fixme now.

from deprecated-bc.

Thanks, as I said, I'd lost this thread of discussion, despite participating in #101. Closing.

from deprecated-bc.