Giters

python-babel / babel

The official repository for Babel, the Python Internationalization Library

Home Page:http://babel.pocoo.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Make setuptools an optional dependency?

akx opened this issue · comments

commented

It's a bit rough that this forces setuptools on everyone that has babel in their dependency chain - is there a plan to remove it again eventually? Could this be made an optional feature?

Originally posted by @sigma67 in #1031 (comment)

commented

OK so the issue is... the file "babel/messages/frontend.py" implements the setuptools commands integration and the command line interface of pybabel itself, and these two implementations are very tightly connected.

Sure it would be nice to make the setuptools commands integration optional, but:

  • It will be a breaking change for tools that still depend on it, no matter how unpopular this is by now.
  • A lot of code may end up being duplicated.
commented

One weird approach to solving this would be to make a new package "babel-core" and move everything except "frontend" into that package. Annoying to maintain, though.

commented

I think most people get babel through the immensely popular sphinx. Not sure if sphinx relies on setuptools functionality of babel.

I think both ideas you mentioned are viable from a user's perspective, either way it will be a breaking change. But it may be a good chance to rework the frontend?

commented

I use the babel CLI (extract-messages, update-catalog, compile-catalog).

What is the “setuptools commands integration”?

commented

setup.py can be used as a "command runner" and this integration allows you to add convenience commands that invoke babel in a particular way.

See this commit (from a project that uses babel) that removes this integration because we don't use setup.py anymore.
mkdocs/mkdocs@12ee265#diff-2450391302526c6fb43e265d1253d6f5fa62ad38c7c8841090760cf9e6d940b3

Documentation:
https://github.com/python-babel/babel/blob/65de3dcf2dc217d6135eff999dc87a3861065e8d/docs/setup.rst

commented

TBH, I think we can do with a fairly small translation/emulation layer so our underlying commands are runner-agnostic, and we have a setuptools wrapper for each of them, and a standalone CLI (argparse) wrapper for them. The latter is already done, really, it's just a matter of un-inheriting the current Commands from the setuptools Command base class and writing the wrapper that way...