Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimalize dependencies and define scope #297

Closed
bunny-therapist opened this issue Jun 7, 2023 · 1 comment
Closed

Minimalize dependencies and define scope #297

bunny-therapist opened this issue Jun 7, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@bunny-therapist
Copy link

bunny-therapist commented Jun 7, 2023

Recently, several dependencies were extracted into "extras", which I think was a great move. I only wish it would go further.

We are currently using benedict exclusively for the keypath functionality and some general dict-utility functionality like "flatten". Because we are using benedict, we get an additional 6 dependencies (benedict has 7, but we already have requests as a dependency). As far as I can tell, most of these dependencies are only used in special utility functions like "get_string" and similar.

To me, the scope of python-benedict is unclear. The dict functionality is very useful (and, I suspect, the main thing people use from benedict?), but there is a plethora of functions like "get_string", "get_slug", "get_phonenumber", "get_datetime", etc, that all seem extremely specific and niche, and add further dependencies. It is not clear to me what the imagined scope of benedict is; theoretically, you could add a "get_" method for any conceivable object defined in some other library ("get_social_security_number", "get_timestamp", "get_monetary_sum", etc), and it is not clear to me where benedict draws the line. For example, I see issue #249 mentioning support for encrypted data, and I wonder if this will mean that benedict will get additional methods which add more dependencies in the future. Supporting, e.g., parsing of phone numbers in what is to a large extent an extended-dict-handling library already seems to suggest feature creep. As a user, I would have loved it if benedict was just keypath/keyattr/keylist dict with no further dependencies, or if that basic functionality was one library, and then another library with the rest of the functionality was built on top of it.

We are at the point where we are considering developing some alternative to python-benedict simply because of the extra dependencies and us being unsure about the future direction/scope of benedict. Will more dependencies be shifted to extras? Will more dependencies be added to benedict? Is there any limit to the scope of things benedict will support?

Fund with Polar
@bunny-therapist bunny-therapist added the enhancement New feature or request label Jun 7, 2023
@fabiocaccamo
Copy link
Owner

fabiocaccamo commented Jun 7, 2023

@bunny-therapist thank you for the feedback, I really appreciate it and find it very useful.

About

Here you can read a bit of history/scope of the library:
https://dev.to/fabiocaccamo/python-benedict-dict-subclass-with-keypath-support-standardized-io-shortcuts-and-many-utilities-50k2

Requirements

Along the time many features have been added (some requested by users, other for personal needs) and consequently also many requirements have been added.

Recently I moved many requirements to extras and I like the idea to move also all the remaining requirements to extras, the idea is to go zero-requirements by default.

Encryption

In the past I made an encryption utility for a project I worked on and I thought it would have been useful to other users, so I created that issue as "reminder", but I don't know if it will ever see the light.

Anyway... if some encryption utility will be added in the future, it will be surely an extra, so no new requirements will be installed by default, don't worry :)


I hope to have clarified all your doubts.

Repository owner locked and limited conversation to collaborators Jun 7, 2023
@fabiocaccamo fabiocaccamo converted this issue into discussion #298 Jun 7, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants