Annoying dependencies

Question

Annoying dependencies

Opened this issue 8 years ago · 3 comments

I think that this library is very useful and I've used it in a lot of my flask projects.
I've one major issue with the dependencies that it kicks in.
The two python libraries visitors and dominate are mandatory dependencies even though they are used only for WTForms and Flask-Nav libraries integration. Since the usage of these two libraries is optional I think that also visitors and dominate should be optional dependencies.

I had a lot of problem packaging some of my app due to this mandatory dependencies and I think that there are a lot of people out there that decided not to use this library exactly for the same reason.
Using a modular approach and making them optional will make it easier to push this library as package in official repositories of the major linux distributions.

I really hate to start fork project and I hope that we can collaborate to make this very good library even better.

Answer 1 · 2016-11-27T15:25:15.000Z

I think that this library is very useful and I've used it in a lot of my flask projects.
I've one major issue with the dependencies that it kicks in.
The two python libraries visitors and dominate are mandatory dependencies even though they are used only for WTForms and Flask-Nav libraries integration. Since the usage of these two libraries is optional I think that also visitors and dominate should be optional dependencies.

While I'm all for modularity, today the WTForms integration is the defining feature for most users that I encounter. Ironically, Flask-Bootstrap does not depend on WTForms, so there's definately some merit in your observations.

However, at this point it's not worth breaking backwards compatibility for this change, as introducing a manual dependency would break a lot of installations that have come to rely on the old behaviour. Package extras might be a way forward here, but that will at the earliest coincide with a Bootstrap 4 release.

I had a lot of problem packaging some of my app due to this mandatory dependencies and I think that there are a lot of people out there that decided not to use this library exactly for the same reason.

I've on occasion heard of someone not wanting to depend on dominate due to licensing issues, which is a valid concern (if a very gray area) --- I'd much prefer an alternative myself, but I have asked the dominate author and he gave me to understand the licensing was not an accident.

I would wager most deployments are simply done through pip, since distro packages tend to be a few years behind often.

Using a modular approach and making them optional will make it easier to push this library as package in official repositories of the major linux distributions.

True, but most of these will not want to package Flask-Bootstrap without forms support.

I really hate to start fork project and I hope that we can collaborate to make this very good library even better.

In this issue I can't help you, unfortunately. You could check the 323 forks of this library on github already, maybe someone has already implemented the changes you need.

Answer 2 · 2016-11-27T18:46:34.000Z

On 11/27/2016 04:25 PM, Marc Brinkmann wrote: I think that this library is very useful and I've used it in a lot of my flask projects. I've one major issue with the dependencies that it kicks in. The two python libraries visitors and dominate are mandatory dependencies even though they are used only for WTForms and Flask-Nav libraries integration. Since the usage of these two libraries is optional I think that also visitors and dominate should be optional dependencies. While I'm all for modularity, today the WTForms integration is the defining feature for most users that I encounter. Ironically, Flask-Bootstrap does not depend on WTForms, so there's definately some merit in your observations. However, at this point it's not worth breaking backwards compatibility for this change, as introducing a manual dependency would break a lot of installations that have come to rely on the old behaviour. Package extras might be a way forward here, but that will at the earliest coincide with a Bootstrap 4 release.

I'm looking forward to a Bootstrap 4 release that make use of optional dependencies. I'm ready to collaborate to the new release.

I had a lot of problem packaging some of my app due to this mandatory dependencies and I think that there are a lot of people out there that decided not to use this library exactly for the same reason. I've on occasion heard of someone not wanting to depend on dominate due to licensing issues, which is a valid concern (if a very gray area) --- I'd much prefer an alternative myself, but I have asked the dominate author and he gave me to understand the licensing was not an accident. I would wager most deployments are simply done through pip, since distro packages tend to be a few years behind often.

That's not true on Arch linux :)

Using a modular approach and making them optional will make it easier to push this library as package in official repositories of the major linux distributions. True, but most of these will not want to package Flask-Bootstrap without forms support. I really hate to start fork project and I hope that we can collaborate to make this very good library even better. In this issue I can't help you, unfortunately. You could check the 323 forks of this library on github already, maybe someone has already implemented the changes you need.

According to you, can the visitors/dominate approach be substitute by an implementation that use only jinja2? It will be really nice because jinja2 is mandatory dep for Flask. Ah.. thanks again for this useful library

Answer 3 · 2016-11-27T21:19:45.000Z

That's not true on Arch linux :)

Well, considering Flask-Bootstrap is on AUR already (https://aur.archlinux.org/packages/python-flask-bootstrap/), including dependencies (https://aur.archlinux.org/packages/python-dominate/ , https://aur.archlinux.org/packages/python-visitor/), this whole thing seems to a non-issue.

According to you, can the visitors/dominate approach be substitute by an
implementation that use only jinja2?

It is actually going the other direction, the jinja2-based approach is not feasible in the longterm, as the macros get too complicated. The visitor-based approach is much cleaner.