-
-
Notifications
You must be signed in to change notification settings - Fork 855
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
Comments
Will the maintainers act on this or do you want me to send the pull request? |
@zvezdan Jira package is not used only as a library, is also used as I am curious on which platform did you find ipython as hard or impossible to install? |
@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 Most of the people don't need ipython in their apps. They would continue depending on 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 |
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 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 |
@ssbarnea That is very good news! Thank you. Can we make library the default without any need to specify the extra with 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 |
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 ( 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. |
I'm not opposed to installing all of See for example SQLAlchemy.
That's a pretty standard technique. I just think that long-time users should have no surprises. Users who need it on the command line never had Principle of least surprise. |
Closing because devel branch just fixed that. Next release will not install ipython. |
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.
The text was updated successfully, but these errors were encountered: