Integration model for Prettier + Python

[taion]

This plugin stuff looks great!

I don't have a concrete proposal here, yet, but I'd like to raise a point about how integration should look. As a Python user, ideally I'd like my workflow to look something like:

$ brew install prettier
$ pip install prettier # Or maybe prettier-python.

Why? Well, it's nice not to have to reach out to npm when I'm working with Python. Additionally, while the vendoring here certainly works, it's not quite ideal (you'd have to tweak PYTHONPATH to scale things up).

It shouldn't be difficult to pull in the doc builders from Prettier and write them in Python, for example, which then ought to open up implementing all of this in Python.

The question, then, would be how to actually register the plugin.

[azz]

You'll still need node installed for Prettier itself, but we could definitely do things to streamline that install.

[taion]

Right – I wonder if you could use Homebrew to install Prettier though.

[taion]

Or, like, make pip install prettier pull down both the core (somehow) and the Python plugin.

[taion]

The thing I'd ultimately like to have is just:

$ pip install flake8-prettier

Like with eslint-plugin-prettier, and be able to think minimally about npm/Node in this context.

Consider someone running the equivalent of that in Travis or whatever – it's not always possible or convenient to pull in a Node runtime just to run my Python build pipeline.

[taion]

(Of course that isn't possible right now, but a plugin-style architecture that makes the Node API just a client might make that possible downstream. As noted, the printing isn't the hard part, necessarily – so much as the rest of the stuff that Prettier Core offers, which could be useful in a multi-language project.)

[Timer]

You could make it a self-contained executable with pkg.

[taion]

My main concern here is less containing the Python parts than containing the Node parts. Ultimately, this project needs to target Python devs and work with Python workflows.

[taion]

Starting to wonder if round-tripping through Node is a great idea. Given little inconsistencies like 479ecce#r26507439, it may be better to just pickle the AST, especially if we do the printing in Python.

That does bring up the question of how to make multi-parsers work, though.

[taion]

Moving this back from prettier/prettier#3503.

ATM the most promising short-term approach seems to be to move the printing logic into Python, and have the "parser" output something closer to what most Prettier printers output, and make the printer be more of a stub. That's because there isn't a good canonical representation of the Python AST in JS anyway, so the distinction is somewhat moot.

That should be enough to make further progress here. If it turns out that, as with Markdown, the core Prettier printing code needs extensive modifications to work with Python, or if it becomes pressing to integrate with something like Flake8, then other things might be required down the road, but it's not really pressing.

[azz]

as with Markdown, the core Prettier printing code needs extensive modifications

That's an overstatement, the changes required were only to support the blockquote format:

> lorem ipsum dollar
> stat amit.

And those changes were generic so we can support any kind of line break/ wrapping characters now.

I doubt Python will require any changes to Doc.

[taion]

That’s great to hear, then.

[bd82]

Could someone help me understand the constraints and requirements?

What I understood so far:

• The plugin targets mainly python developers.
• Python developers do not want to to deal with node.js runtime and dependencies.

What I did not understand is:

• How would moving the printing code to python make a difference if the base prettier library
  which is written in JavaScript has to be loaded anyhow?

What I'd like to ask is:

• Would a python parser written in JavaScript assist this project in any manner?

Thanks.