FIX import: create publication without existing index.md

[christianbrodbeck]

When running % academic import --bibtex ~/pubs.bib for the first time I got the error below, seemingly because the script was trying to read a non-existing index.md file. With this fix I could run the import successfully. I still get the need to install Go message despite having installed go (I can run hugo server), but it does not seem to cause any issues.

Error: we found a go.mod file in your project, but you need to install Go to use it. See https://golang.org/dl/.: module "github.com/wowchemy/wowchemy-hugo-modules/wowchemy" not found; either add it as a Hugo Module or store it in "/Users/christian/Code/christianbrodbeck.net/themes".: module does not exist
Traceback (most recent call last):
  File "/Users/christian/anaconda3/envs/academic/bin/academic", line 33, in <module>
    sys.exit(load_entry_point('academic', 'console_scripts', 'academic')())
  File "/Users/christian/Code/academic-admin/academic/cli.py", line 43, in main
    parse_args(sys.argv[1:])  # Strip command name, leave just args.
  File "/Users/christian/Code/academic-admin/academic/cli.py", line 101, in parse_args
    import_bibtex(
  File "/Users/christian/Code/academic-admin/academic/import_bibtex.py", line 55, in import_bibtex
    parse_bibtex_entry(
  File "/Users/christian/Code/academic-admin/academic/import_bibtex.py", line 100, in parse_bibtex_entry
    page.load("index.md")
  File "/Users/christian/Code/academic-admin/academic/editFM.py", line 23, in load
    file = open(self.path, "r").readlines()
FileNotFoundError: [Errno 2] No such file or directory: 'content/publication/gramfort-mne-2014/index.md'

[gcushen]

@ionlights are you able to review this - sounds like it might be another bug introduced by #68 ?

[jmuchovej]

@christianbrodbeck Just checking - you've run into two errors?

1. The EditableFM doesn't find your index.md.
2. You don't get the "passthrough to hugo" when using academic.

Is that correct?

[christianbrodbeck]

1 was an error, 2 is just something that's printed in the console, it does not seem to have any adverse effects (I don't know what to expect to happen with hugo at that stage? Is the command supposed to do more than create the markdown files for the publications?)

[jmuchovej]

Yea, if you pass in a command and it's not a known academic command, it'll get passed to hugo (either via Docker or your local installation).

[christianbrodbeck]

When I run the command after applying the fix in this PR then the hugo error seems to get printed once for each publication that's processed, i.e.

 % academic import --bibtex ~/pubs.bib
Error: we found a go.mod file in your project, but you need to install Go to use it. See https://golang.org/dl/.: module "github.com/wowchemy/wowchemy-hugo-modules/wowchemy" not found; either add it as a Hugo Module or store it in "/Users/christian/Code/christianbrodbeck.net/themes".: module does not exist
Error: we found a go.mod file in your project, but you need to install Go to use it. See https://golang.org/dl/.: module "github.com/wowchemy/wowchemy-hugo-modules/wowchemy" not found; either add it as a Hugo Module or store it in "/Users/christian/Code/christianbrodbeck.net/themes".: module does not exist
Error: we found a go.mod file in your project, but you need to install Go to use it. See https://golang.org/dl/.: module "github.com/wowchemy/wowchemy-hugo-modules/wowchemy" not found; either add it as a Hugo Module or store it in "/Users/christian/Code/christianbrodbeck.net/themes".: module does not exist
...

[jmuchovej]

Hmm... weird. Not sure what those go errors are.

So, @gcushen I see two ways forward with this:

1. This PR gets approved and side-steps the need for hugo new ... (since it'll create the find regardless of archetypes with .dump(), which also means it may miss out on some of the archetype's fields).
   • If this is the desired route, everything looks good, just up to you if you think if...else is preferable to try...except FileNotFoundError...finally.
2. Don't merge the PR and diagnose why @christianbrodbeck is running into these go issues. (I think this is really the culprit.) If hugo new ... is doing it's job, .../index.md should be there already. EditFM does exactly that, it parses and edits existing files. It doesn't make them, or at least that was my intent – let hugo do the creation.

[christianbrodbeck]

So I still had the same terminal in which the error happened open, and I tried to run hugo by itself, and it complained about missing go. In a new terminal it does not. I suspect what happened is that the terminal was open already before I installed go, and that go requires any terminal to be restarted after installing.

Does the hugo new command do anything in addition to creating the index.md file? It seems like I ended up with working website despite the error.

[jmuchovej]

So, if you look at the themes/.../archetypes folder (I think it's a relatively top-level directory, like content) – you'll see a few different folders, one of which is publication. Basically publication pre-loads a lot of front-matter (the stuff between --- ... ---). The main utility of using hugo new ... over manually creating the file is that academic-admin relies on the installed template's archetype rather than academic-admin potentially having a clashing implementation.

For this particular case, this entire script generates index.md and a cite.bib in the same folder. IIRC, the latter is done via academic-admin, so it doesn't rely on hugo.

[christianbrodbeck]

I only found an empty themes folder in my repository (very recent clone of starter-academic, just using the default theme), but if there is potentially more work done it would probably make sense to raise a proper error when hugo fails instead of the workaround in this PR?

[gcushen]

@ionlights I propose we remove the dependency on using Hugo to generate the publications (with hugo new), similar to before #68 . We can create a template publication file in this repo based on the current archetype and use that.

This proposal may provide some nice benefits for the project:

• More intuitive - no need for user to install Hugo and its dependencies locally. User could run the tool to generate the publication Markdown files and then directly upload them to their Github repo if they want.
• Enables this project to be used to convert Bibtex for use with other Hugo themes that might not have a publication archetype
• Enables the project to be used with other static site generators besides Hugo (e.g. portable solution if a user ever decided to migrate from Hugo)

[jmuchovej]

@gcushen All right – at first blush, that means we'll also need to add another flag for the publication directory. The default could be pwd or content/publication.

Additionally, I'm not sure portability is as easy as it sounds? (e.g. with Jekyll, if folks wanted sorting of their publications, they need the date formatted in the title, additionally, cite.bib would need to go elsewhere.)

While I think having this as a generic publication generator would be cool. I'm not sure how well it would hold up in practice – layout logic differs across SSGs.

How frequently have you changed the publication archetype in hugo-academic? (wowchemy?)

[jmuchovej]

@gcushen Just a bump. 🙂
https://github.com/wowchemy/hugo-academic-cli/pull/73#issuecomment-696704496

[gcushen]

@ionlights the publication archetype can be found here: https://github.com/wowchemy/wowchemy-hugo-modules/blob/master/wowchemy/archetypes/publication/index.md . It's history can be viewed on Github by heading to the repo root, choosing a tag, and looking in its previous location at archetypes/publication/index.md.

A compromise could be to add a flag to default to using a minimal static built-in template of core front matter parameters (removing the Hugo and Wowchemy dependencies whilst generalising the tool), whilst giving an option for Wowchemy/Academic power users to use the #68 approach of automated hugo new to generate pub. files with the more comprehensive range of front matter options for the Academic Starter template.

This might also enable more comprehensive unit testing without requiring integration (with a Wowchemy site and Hugo) testing to test actual file generation.

[jmuchovej]

Lol. I forgot to look at Blame. 😂 So, it seems like the archetype has been relatively unchanging.

I think that having a core set but allowing folks using Academic to leverage the extras is good. Presumably, we can use the path to infer their config/_default/config.toml and read out either theme = "academic" or module.imports.path = ...? What are your thoughts on that?

Also, the Docker support might need to be dropped. I ran into some interesting issues with jojomi/hugo:XX when trying to use the newer approach of modules.

I'm not sure what you're getting at about Unit Testing. Can you elaborate on that?

[gcushen]

Great idea, rather than having another CLI flag, we could just check if a config/_default/config.toml exists, or if not, if config.toml exists, and do a simple search within the file for wowchemy, theme = "academic", and theme = "hugo-academic".

We're working on a Wowchemy-specific Docker for GitHub's new online code editor. It will include Go and this Academic CLI. Feel free to contribute: https://github.com/wowchemy/wowchemy-hugo-modules/issues/1848

As for testing, I mean that really #68 introduces the need for integration testing given the use of hugo new. Integration testing of the CLI may be slightly less important to implement if Hugo is not a required dependency.

[gcushen]

Moving the outcome of this discussion to a new issue, #85 . Feel free to get involved :)