1. You can create a Custom environment by writing a Dockerfile with all the libraries you need to install and everytime you're in a need to re-use a similar functionality (e.g. convert yet another book to mobi), you can just fire it up and all will be preinstalled.
https://docs.deepnote.com/environment/custom-environments
2. You can turn any notebook to a blogpost right away and publish within Deepnote directly.
Wait this is a notebook similar to pythons' notebook but it's a docker environment where I can install a lot of stuff I want and then do even more stuff? Am i getting this right?
It's like a shell to a vm but in a notebook format that you can then use to blog?
what would be advantages to going to Deepnote from regular Jupyter notebooks based workflow?
Let's assume someone who has been working with Jupyter notebooks(mostly Python based) for a long time.
Are Deepnote notebooks exportable?
The big worry is that you guys decide to pivot or radically change your pricing model and there is no offramp.
By comparison I don't mind using Google Colab. If Google Colab decides to shutdown or 100x their price I can take my .ipynb files and use them on my local littlest JupyterHub instance.
Deepnote internally supports .ipynb format and you can always export the Deepnote notebook to .ipynb similarly as you'd in Colab.
In general the main selling points are live collaboration (you can work on a notebook with you team as you'd do on a google doc), and integrations (you can plug-in your snowflake db, or s3 bucket or whatever, and have it connected for any further analysis, or a long-term training, etc.
For many non-software-developer data scientists, it's also easier to work in a cloud environment compared to installing stuff locally, and to version their notebooks in Deepnote instead of git. But this really depends on the particular workflow that one has.
I can absolutely see a need for collaboration tool.
Collaboration on regular Jupyter is a pain. I create a shared folder for coworkers and well read/write permissions* are not fun.
I followed a similar approach for my novel; started with Markdown, used pandoc to convert it to epub/mobi, but also to LibreOffice .odt to generate the PDF for the paperback. Wrote some details about the process here: https://gabrielgambetta.com/tgs-open-source.html
Don't want to be a troll, but if you are writing anything that is not a README and/or is a book or booklet or bookish, do yourself a favor and use Asciidoc instead.
This! Asciidoc is the grown-up brother of Markdown. Designed to scale up to entire books, handle images, tables, references, citation, book indexes, maths.
Absolutely. AsciiDoc (2002) is actually 2 years older than Markdown (2004), but is surprisingly similar to write.
It was created as an equivalent to DocBook XML for the creation of book-length technical documents. It has a rich history and is well supported in many places (try writing a README.adoc for your next GitHub-hosted repo).
It is also currently undergoing a standardization process:
I assume the person you're replying to was referring to Markdown rather than Bookdown. It seems that Asciidoc was designed for the direction which Markdown has going with all these variants. If you find yourself chasing these Markdown variants to get more flexibility, then Asciidoc might be what you're looking for.
I don't know anything about Bookdown and it may be similar to Asciidoc. I would be willing to bet that Asciidoc would be around longer than most of the MD variants though.
Why might you want to continue using MD flavors? You already have loads of MD docs and you have no control over the processes which create them (shared environment, higher-ups force you to use MD, etc.)
NOTE: If you're interested in Asciidoc, also take a look at Asciidoctor.
This is a nice tutorial, thanks for submitting it! However, for me, the biggest discovery was epub.press [0]. I just tried for couple of open pages, it works quite well!
Calibre website strongly recommends downloading from their site instead of OS packages, mentioning that the packages are often out of date. And I've generally found this to be true - Calibre versions on package repos are often several versions behind, more than the usual "package maintainer trying to play catch up" differences.
I'm usually averse to the wget|sh installs, but in this case it seems worth it. You can inspect the .sh file (which is really mostly Python code) before running it, just to not get into the bad habit of directly piping in code from the internet.
That's not the issue. Installing software this way means you have no automatic updates in the future. It's fine if you re-run the install script on a regular basis (eg. by recreating containers) AND you don't pin versions
But OP's instructions fail both: there is no mention of updates, and they pin the pandoc version.
I use pandoc in a CD pipeline, the version in the repos is stale compared to upstream (normal, that's how it is) unless you're on a rolling distro like Arch.
I have reported pandoc bugs and had them fixed (great dev team), pulling the latest single-DEB install (no deps, unlike the one in the Debian repo) and using it gets all the latest updates which matter to a process like this.
In this particular case your needs to use the latest pandoc lead to the wget pull and install, which thanks to their DEB design is easy and clean to do in an ephemeral CI container.
Sure thing, it's pretty simple and straightforward I can post right here. In your CI/CD runner, you add a "before" script like so (Gitlab YAML example):
The Github API used above has the nice default of listing the latest release as you see used there in the grep on the right, one could enhance that with `jq` for higher intelligence but this very simple setup is functional as a starting point to develop your own style.
The tutorial is presented well. My biggest takeaway was that one can use 'Deepnote' to run Linux commands.
If you are interested in knowing how to customize `pandoc` for generating PDF/EPUB, I have a tutorial [0] based on books I've written. I also have links at the end with related resources, including tools others than `pandoc`.
Jupyter notebook also has the same feature. `!shell command` or start a cell with `%%bash` and everything in it will run through the terminal, not the notebook interpreter.
That'd require you to have access to a *nix terminal on your system. Deepnote is allowing access through their servers, so for example, you can try this tutorial on Windows.
However, Kindles can't read epub directly. If you're trying to produce a file you can sideload on your (or your customer's) Kindle without going through Amazon, you're still gonna need mobi, or one of the later proprietary (and undocumented) Amazon mobi variants.
I recently started converting Markdown files to epub (and kepub) for my new Kobo. I load the Markdown straight into Calibre though.
On a side note, is there some benefit to mobi over epub? Kepub seems to be the preferred format on Kobo, because for some reason it turns pages _much_ faster than epub and gives access to reader statistics (if one cares about that).
Hey, I'm curious about your Calibre usage! I'm working on turning a written book to Markdown, and pandoc has a real pain point on links between chapters. Please tell me more!
What would you like to know? In Calibre you can set regex to indicate what should be used for chapter, sub chapter etc, and it can be used to generate the TOC. So I use Markdown headings, #, ##, ### etc for chapters and subsections.
Checking, it looks like Calibre expects one Markdown file as input, where I have a few Markdown files, linking to each other in a way that works on GitHub. It looks like the sort of thing that either works as-is with luck, or is a pain in the neck and needs massaging.
Good stuff. When I wrote an eBook I found the extra features of reStructuredText to be useful (index, glossary, graphviz & Tikz environments, etc.) and wrote a sort of similar post.
Yeah the rSt markup is pretty idiosyncratic and both anal-retentive and a bit inconsistent (e.g. it can be hard to internalise where it does or does not want blank lines) but Sphinx is an actual document system, having to work with markdown for anything beyond a single file quickly gets painful.
You know, I bet it wouldn't take that much to go from epub to PDF, suitable for printing and binding. The structural information is pretty much all there, I think - it'd just need pagination and formatting for print, really.
I'd definitely want to use such a thing, as a way to feed my bookbinding hobby. I wonder if anyone else would?
Unfortunately, the renderer that gets used will sometimes itself depend on the file. For example, if you transfer the generated Mobi file to a Kindle as the article says, it will get rendered using an inferior renderer (in terms of kerning, for example) compared to the renderer that would've been used had the file been a KFX ("Kindle Format 10").
I would like to have better type setting. It is a pleasure to have a nicely layouted and set page. My layman's take would be that the rendering engines have headroom to improve but most readers don't really care.
Here's a public notebook in Deepnote if anyone wants to play around with the code or duplicate it: https://deepnote.com/project/Converting-Markdown-to-Epub-or-...
2 fun facts about Deepnote:
1. You can create a Custom environment by writing a Dockerfile with all the libraries you need to install and everytime you're in a need to re-use a similar functionality (e.g. convert yet another book to mobi), you can just fire it up and all will be preinstalled. https://docs.deepnote.com/environment/custom-environments
2. You can turn any notebook to a blogpost right away and publish within Deepnote directly.
Disclaimer: I'm a software engineer at Deepnote.