Skip to content
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

The library should not depend on a framework/executable #390

Closed
zvezdan opened this issue May 5, 2017 · 8 comments
Closed

The library should not depend on a framework/executable #390

zvezdan opened this issue May 5, 2017 · 8 comments
Assignees
Labels
Milestone

Comments

@zvezdan
Copy link

zvezdan commented May 5, 2017

Issue #361 was resolved by adding ipython into install requirements of the jira.
This is a request to revert that change, please.

This package is used as a library.
Why would you add ipython as its dependency?
If some other executable based on this library needs ipython, it should declare it as its own dependency.

Forcing library users of completely different applications to depend on ipython is not a good idea.
IPython is a huge dependency (executable/framework) and self-contained apps do not need it.
They just need this library (jira).

If jira's code base is not using ipython's features directly, then it is not its direct dependency.
Jira does not need ipython to build or run its code (consumed by an executable app), AFAIK.

Please remove this artificial dependency.
Otherwise, you may break a lot of library consumers in the next release.

@zvezdan
Copy link
Author

zvezdan commented May 23, 2017

Will the maintainers act on this or do you want me to send the pull request?
The jira package should not be released with this dependency because it'll break packages that depend on it.

@ssbarnea
Copy link
Member

@zvezdan Jira package is not used only as a library, is also used as cli tool. If you use it as a library you can always ignore the requirements and specify them manually.

I am curious on which platform did you find ipython as hard or impossible to install?

@zvezdan
Copy link
Author

zvezdan commented May 23, 2017

@ssbarnea That is exactly the problem. Why is the library not separate from the executable? That executable (other package) could depend on jira library.

Alternatively, if you want to keep them together then jira should use extras_require and have people who want to use it as cli tool install it with jira[cli] where the cli extra would require ipython. That's similar to how one can install ipython[notebook] to get extra dependencies needed for IPython notebooks.

Most of the people don't need ipython in their apps. They would continue depending on jira and they would get only dependencies needed for the library. The ipython dependency would be excluded without an extra being required.

I can send a pull request for that change if you want although it would be nice if maintainers actually reverted the incompatible change made recently in #361.

The issue is not in whether ipython can be installed, but in the number of unnecessary other dependencies it can bring or just a simple fact that it's an unneeded dependency that is very large.

Don't forget that most large Python shops install packages using a build system of some sort, not by running pip install manually. This change would affect those users the most. Providing an extras_require correctly would prevent surprises in such builds.

@ssbarnea
Copy link
Member

I created a branch for testing a solution to this problem because that was a recurrent issue, different users did had different expectations (library vs cli).

My initial intention is to include both by default but to allow people to use only the library if they want, by adding a requirement like jira[library].

Feel free to play with that branch first, and let me know if it works or not for you. My initial tests are positive, I was able to control what I install using pip install [library|cli|opt|testing]. I still need to test how last change affects the built wheel.

@zvezdan
Copy link
Author

zvezdan commented May 23, 2017

@ssbarnea That is very good news! Thank you.

Can we make library the default without any need to specify the extra with jira[library].
Instead having just jira in the dependencies as before would continue working as it used to.
That way the existing builds will just continue working without the need for change.

Principle of least surprise to the users (consumers of the package).

Since ipython dependency was a recent addition to dependencies, without any release with it, no one would get surprised if they need to add jira[cli] for its use as an executable.

@ssbarnea
Copy link
Member

Before making a decision I will make a survey on this, the package is made of two components and I do like having both installed by default (pip install jira).

So I added this as a question on https://stackoverflow.com/questions/44165253/should-cli-commands-be-installed-by-default-with-python-libraries as I am quite curious what people would opt-in for, the same question could apply for many other libraries that do come with cli tools.

@zvezdan
Copy link
Author

zvezdan commented May 25, 2017

I'm not opposed to installing all of jira code by default.
What does not need to be installed by default is a large dependency (ipython)
The code that needs ipython can check if it's present and give a message to the user to install it in a different way or add ipython to their virtualenv, ...

See for example SQLAlchemy.
It does not know which backend of many that it supports, the user will have.
It uses:

try:
    import some_sql_backend_db
except ImportError:
    # do something else if not present

That's a pretty standard technique.
Imagine them forcing all users to install all the backends they can use?

I just think that long-time users should have no surprises.
Especially users who install jira with automated build tooling.
The ipython dependency is a big and surprising change for them.

Users who need it on the command line never had ipython added by jira before.
Having it would be a benefit, but not having is is not a surprise for them.
Getting it by using install with jira[cli] is not too much of additional change for such users with the added benefit of getting IPython with it.

Principle of least surprise.
I've worked on large Python open-source projects and know what it means to support users as correctly as we can.
I am sure that this is the right approach.

@ssbarnea ssbarnea self-assigned this Jul 14, 2017
@ssbarnea ssbarnea added the bug label Jul 14, 2017
@ssbarnea ssbarnea added this to the 1.1.0 milestone Jul 14, 2017
@ssbarnea
Copy link
Member

Closing because devel branch just fixed that. Next release will not install ipython.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants