Companion files comments

[fperez]

Include remaining comments that weren't fully addressed before merging PR 15, so we capture complete discussion in this file.

[takluyver]

Kyle, what would be the advantage of using asar? To me, that seems much
more like reinventing the wheel than zip, which is extremely well
established.

[fperez]

Ping @rgbkrk in case he's not subscribed...

[rgbkrk]

what would be the advantage of using asar

• Random access support
• Safety from the long file paths issue on Windows

If the project cared about it from an Electron perspective, any Electron app can read from asar files even being able to require from them. I do recognize it's not in the charter for Jupyter to care about Electron based apps. That's ok!

Main drawback is that there aren't any major Python implementations of asar unpacking other than the semi-implemented pyasar.

I'm not going to push hard on this one though, just threw it out as an option since I'm familiar with it and enjoy the semantics better than zip plus creating yet another protocol (would rather us define another JSON schema on top of something like asar). That's my 2 cents.

[takluyver]

• All the things we're currently thinking of putting in there will be loaded as whole files - maybe there will be something later that used random access into the middle of a file, but I find it hard to imagine what. If we're thinking of storing something like an sqlite database, I'm pretty sure it would still need to be outside any kind of archive.
• I appreciate that it's super easy for electron to load asar, but I'm confident that it's quite easy for code in any language to use zip files. Buying a bit of convenience in one technology by using something which is not widely supported elsewhere seems like the wrong tradeoff.
• I hope the protocol won't need to be too complex. I know it's easy to hope, though - maybe we should start trying to design the protocol, and see what it looks like.

(Bullet points to keep it short, I'm not trying to be dismissive)

[fperez]

It's not a matter of "not caring" about Electron: at least I do care a lot, and I want to maximize ease of interoperability as much as we can. But in this case, asar is an Electron-specific tool/technology without even any complete Python support, whereas (as Thomas says), zip is so ubiquitous that pretty much any language in common use today can handle it.

So I think it's OK to keep this idea in mind as we move forward, but for the sake of simplicity (zip is supported even in the python stdlib) as we start, I suggest we go with something that's ubiquitous...

I'll make a quick update to the doc to leave the asar reference but as a note only.

[rgbkrk]

Sounds good to me.