Improve manifest: Add Markdown/HTML to template descriptions, add human-readable title

[jancurn]

How about we allow using Markdown or HTML in the template descriptions in manifset? Plus add a new filed title with a human-friendly name, rather than have this crazy parsing.

That would let us make the descriptions in the UI more informative. Most people have no idea what is e.g. CheerioCrawler. I guess we'd only need to support this in apify-core (that's simple) and in CLI (probably also simple). What do you think @fnesveda @mnmkng ?

[mnmkng]

I would probably prefer some JSON API for it rather than markdown. The platform should control the structure. This repo should only provide data.

[jancurn]

JSON API as in add one more field "detailsUrl" ? That could work too...

[mnmkng]

I meant that it would expect the manifest in a pre-defined format, but fetching it from URL could work as well.

{
  id: 'CheerioCrawler'
  title: 'Simple HTTP crawler',
  description: 'Some description',
  tags: ['cheerio', 'http', 'easy', 'fast']
  someOtherParam: '...'
}

The platform would define what params are available and we would add them to the manifest. The platform UI would then be responsible for rendering this data however it wants. The difference from now is that when we were creating the manifest, we were modeling it to match the CLI so it does not include a lot of human readable data.

[fnesveda]

I am all in for improving this package and the metadata it offers, we could also add things like defaultFile, which would indicate which file to open by default when viewing the actor in the multifile editor, like main.py or main.js. As for the details, I think having a rich description in Markdown would offer more flexibility for rendering in app, but having just a link to details would be fine too. Or having both description and richDescription fields.

I also think we should version the package more, and always tag the commit on release. Currently we're always downloading the manifest and template zips from master (at least in app, but I think CLI does it similarly), which is complicating making some structural changes to the templates, because it would break everything which downloads these packages.

[jancurn]

So how about starting with this by doing a PR, where we'll extend the manifest with the new fields (and keep the old ones to make it backwards compatible). Once merged, we can use those in UI and potentially also CLI

[mnmkng]

I would prefer this to first be decided on the platform level. They should know where they want to display the data, how it should look, what kind of data it should be and so on. The change here will be trivial afterwards.

[jancurn]

It's only shown in the view above and frankly, it sucks as it is now. As a bare minimum I'd want to add a link there so people can see what it is, plus human-readable title (now it's a class name extracted from the description). I don't think we need too much of a discussion to add these two fields ... otherwise, this will take 3 months to get done...

[mnmkng]

Yeah, I can add the fields now, but we'll still have to wait for platform to implement it. I don't see how making the change here helps anything. Am I missing something? Once they have the components, I can add the content in 10 minutes 🤷‍♂️

[B4nan]

Closing as I believe this is no longer relevant.