Provide package API to use programmatically #20

New Issue

Barbagus · 2022-12-27T07:43:54Z

Barbagus commented

2022-12-27 07:43:54 +00:00

So far this package only provides a CLI access, I suggest providing a API access (through functions importable from __init__) so this package can be used by other programs.

So far this package only provides a CLI access, I suggest providing a API access (through functions importable from `__init__`) so this package can be used by other programs.

Barbagus referenced this issue from a commit

2022-12-27 07:56:24 +00:00

Provide programmatic access #20

Barbagus commented

2022-12-27 08:00:42 +00:00

After fad48ff661 The muxing (FFMPEG) still prints to stdout, this should be hidden for a clean API access.

Also, errors should be exposed in __init__

After fad48ff661 The muxing (FFMPEG) still prints to `stdout`, this should be hidden for a clean API access. Also, errors should be exposed in `__init__`

Barbagus referenced this issue from a commit

2022-12-29 07:54:03 +00:00

Provide programmatic access #20

Barbagus added the

enhancement

label 2022-12-30 07:54:52 +00:00

Barbagus referenced this issue from a commit

2023-01-08 19:12:36 +00:00

Cleanup package API #20

Barbagus closed this issue

2023-01-08 19:13:42 +00:00

Barbagus referenced this issue from a commit

2023-01-09 18:48:46 +00:00

Refactor models and API

Barbagus reopened this issue

2023-01-09 18:49:59 +00:00

Barbagus referenced this issue from a commit

2023-01-24 08:30:11 +00:00

Split program/rendition/variant/target operations

Barbagus commented

2023-01-24 19:27:23 +00:00

The muxing (FFMPEG) still prints to stdout, this should be hidden for a clean API access.

The muxing (FFMPEG) still prints to `stdout`, this should be hidden for a clean API access.

Barbagus commented

2023-01-25 08:19:14 +00:00

One could argue that in order for the API to be as flexible/useful as possible, its scope should be on the actual ArteTV business... for example: the fetch/download (and its dependency on requests) and the actual muxing could/should be externalized.

For the muxing, we could imagine the API to only provide the command line to run FFMPEG but not running it.

For the fetch/download, two strategies come to mind:

Feed the function with pre-fetched data and/or path to file were downloaded data is stored.
Provide callback functions to the API call so users can implement it the way they want.

While 2. provides better flexibility (in the API should ever do multiple or conditional fetches), 1. is somehow "cleaner" and less of a machinery.

Opinions ?

Note: the difference I am making between fetch and download is whether it is done in memory or on disk.

One could argue that in order for the API to be as flexible/useful as possible, its scope should be on the actual ArteTV business... for example: the fetch/download (and its dependency on `requests`) and the actual muxing could/should be externalized. For the muxing, we could imagine the API to only provide the command line to run FFMPEG but not running it. For the fetch/download, two strategies come to mind: 1. Feed the function with pre-fetched data and/or path to file were downloaded data is stored. 2. Provide callback functions to the API call so users can implement it the way they want. While 2. provides better flexibility (in the API should ever do multiple or conditional fetches), 1. is somehow "cleaner" and less of a machinery. Opinions ? Note: the difference I am making between fetch and download is whether it is done in memory or on disk.

Sign in to join this conversation.