res: define the primary f-utils libs

[ximenesyuri]

Description

To define which should be the primary f-utils libs, in which context-based spectra are constructed. For example, f-json, f-re, f-path, f-http, etc.

[ximenesyuri]

The primary libraries should have a well-defined context, but at same time they should be about fundamental parts of the programming language.

[ximenesyuri]

I think that the primary libs should be independent one each other (i.e, a primary lib should import primitive functions, but should not import other primary libs).

[ximenesyuri]

In my opinion, one should begin with the following primary libs:

1. f-ansi: to deal with ANSI
2. f-log: to deal with logs
3. `f-re: to deal with regex
4. f-path: to deal with filepaths
5. f-json: to deal with json
6. f-http: to deal with http requests
7. f-cli: to deal with CLI

[rdvid]

@ximenesyuri i agree.

In my research i stepped with some of the most used python libs grouped by scope that can be a north for new f-libs and modules for those libs as well:

f-os: Operating System & System-Related:
os: Operating system interfaces (files, processes, environment)
sys: System-specific parameters and functions (interpreter details, command-line arguments).
subprocess: Subprocess management.

f-codec: File & Data Handling:
csv: Working with CSV files.
codecs: Encoding and decoding text.
zlib, gzip, bz2, lzma: Compression and decompression.
zipfile: Working with zip archives.

(maybe a extension module of f-http?): Networking:
ssl: TLS/SSL wrapper for sockets.
smtplib: SMTP (email sending).
poplib: POP3 (email receiving).

f-thread: Concurrency & Parallelism:
threading: Threading library.
multiprocessing: Process-based parallelism.
asyncio: Asynchronous I/O.

Under the premise that i have little work contact with some of those lib scopes, let me hear if some of them makes sense by now or serve as a near future goal :)

[ximenesyuri]

Thank you for your investigation, @rdvid.

About having a lib f-os with the given scope, I think that it is too broad. I would like to have things a bit more segmented, so that one could install as a dependence exactly what is needed.

Maybe to have:

1. f-path: deal with paths
2. f-run (or f-sh): replacement for subprocess and other things related to running shell commands
3. f-cli: replacement for argparse and other things related to building

Instead of having just a general f-codec:

1. f-csv: deal with csv files
2. f-zip: deal with compression, decompression and zip/tar files
3. f-codec: encode/decode

I don't known exactly about f-http, but it could be segmented as you suggested. Maybe I could suggest to put SMTP and POP3 in a same library called f-mail.

I liked the scope of f-thread.