Move the pelican tools in a different place?

[almet]

Pelican currently contains a bunch of utilities to support import from other systems and a quickstart command line.

I'm wondering if this serves us or deserve us. I'm opening this discussion so we can know what people think.

Ideas:

• removing the importers from pelican, and put them somewhere else (another "pelican-tools" repo? a gist? If we do that we need to update the documentation accordingly. But the current import script is kinda buggy and doesn't work seamlessly (but it seems some other tools do)
• Adding a flag in the pelican importer to make it not ask for every single deployment platform if you don't need it; That could also be something different, but currently I find it's asking too many questions.

Ideas?

[f0x2501]

I think it's a good principle when utilities not a core functionnality of pelican. There are only use in a particular context and maybe one time during migration. Never during normal process of publication. So I agree with your proposition to consider them as external tools (like a good awk/sed/grep script ^^).

[russkel]

Yeah why not, the same is done with plugins.

[justinmayer]

I agree that we should move the import functions out of Pelican core. That said, I think the quickstart tool should remain as part of Pelican.

Forcing the user to install an external tool in order to run the quickstart process... seems like a sure-fire way to cause undue confusion, induce unnecessary frustration, and reduce end-user adoption.

[avaris]

We could use extras_require from setuptools. It's also supported by pip. So, for example; pip install pelican would install the core only, and pip install pelican[tools] would include the tools.

[smartass101]

I agree with @justinmayer regarding the pelican-quickstart tool.

[Scheirle]

:+1: pelican-quickstart stays in the main repo. Other tools are moved in a separate repo.

[justinmayer]

Glad that there seems to be consensus. Would someone be willing to step forward and take ownership of moving the above-mentioned components to a separate pelican-tools repo?

[shrayasr]

When the repo does happen be sure to merge in #1390. If things go well, I should be able to take this up. But give me a while, I am still reading the codebase.

[iKevinY]

Since it doesn't seem like anyone else is actively working on this at the moment, I think I will work on migrating pelican-import and pelican-themes over to the pelican-tools repository that @kylef has created (see #1410). I like @avaris' suggestion of using extra_requires to optionally install all of the tools alongside the base installation of Pelican, so I am going to go with that approach.

[leotrs]

@iKevinY did this ever get done?

[iKevinY]

@almet @justinmayer @avaris Thoughts on moving forward with this?

[avaris]

I am all for moving tools to their own repo/package.

[almet]

That looks like a good plan.

[liberforce]

Really, this needs to be split.

I'm currently migrating my blog from dotclear to pelican, and the import script is just not doing enough by default. Having it as a tool inside pelican doesn't make really sense, as it's frankly a separate project, with separate tests to avoid regressions, etc. Having it as a separate package would also help to split the code and the different import sources.

I've created a repository for that. I only plan to handle my own blog migration though.

[liberforce]

I've started https://github.com/liberforce/blog2pelican based on pelican import script. I fixed tags and creation date for now for the dotclear parser (based on the format of my own dotclear blog backup).

This is still early work, I've split that into several files to separate the different parsers and builders, making the required dependencies for each parser more clear. But this refactoring is crying for OOP, so that's one of the next steps. Not sure if this will be before the other bugfixes I have on the works, though.

I may still push force on master, so clone at your own risk.