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

Focus on Jedi, reduce Rope dependency #702

Open
jorgenschaefer opened this issue Oct 31, 2015 · 11 comments
Open

Focus on Jedi, reduce Rope dependency #702

jorgenschaefer opened this issue Oct 31, 2015 · 11 comments
Milestone

Comments

@jorgenschaefer
Copy link
Owner

In a discussion on a Rope issue, the current maintainer stated that Rope is not intended to work with source code that is not syntactically correct. That is, Rope is not meant to be used for as-you-type completion or quick call-tips, and any bugs Elpy users find in Rope will be closed as wontfix.

As these are the main features Elpy uses of Rope, we should simply focus on Jedi as a single backend and only optionally support Rope if it's installed.

@jorgenschaefer jorgenschaefer added this to the v1.11 milestone Oct 31, 2015
@emacsway
Copy link

Hi, Jorgen.

I respect you, but I think that your decision is emotional. Rope is excellent library, especially for refactoring. Many peoples uses rope. You can find in rope event commits of Bill Wendling from Google.

I use rope too often.

Now rope has some difficulties with number of real mantainers, but I think that it's temporary.

+1 to retain the rope.

@jorgenschaefer
Copy link
Owner Author

Hello, and thank you for your comment.

This has nothing to do with emotions, but is a simple result of the discussion on python-rope/rope#83 – I was told quite explicitly by the current Rope maintainer that Rope does not intend to make it possible for a library using it to distinguish between bugs in Rope and problems in the source code Rope is analyzing. That makes the library only marginally useful for code completion, on-the-fly documentation, or anything like that. Refactoring is the one feature in Rope I can still see useful.

Do you see problems with using Jedi instead of Rope for these things?

@emacsway
Copy link

Yes, I was read python-rope/rope#83 .

Do you see problems with using Jedi instead of Rope for these things?

First of all, I think, we should not be limited to single solution, and should have several alternatives.

Sometimes I have problems with jedi, and thanks you for #763 - it's also actual for me.

Very often I use refactoring by rope in my work (more info in chapter "Refactoring and Design" of "Refactoring" book by M.Fowler). Currently I use my patched rope with type hinting, because we have too many DIP in project.

Until recently, I used jedi. Now I use more and more rope (my patched) for autocomplete, because it has well type hints for my case (supports for declaration of interfaces and class attributes).

Also, rope has stable API and clean code (excellent codebase), which is easy to change. @aligrudi is a rare talent.

@jorgenschaefer
Copy link
Owner Author

Nice :-) Have you considered pushing those changes upstream?

@emacsway
Copy link

Thanks. Yes, there is pull request python-rope/rope#133

@jorgenschaefer
Copy link
Owner Author

👍

@jorgenschaefer jorgenschaefer modified the milestones: v1.11, v1.12 Jan 25, 2016
@mcepl
Copy link

mcepl commented Jan 29, 2016

This has nothing to do with emotions, but is a simple result of the discussion on python-rope/rope#83 – I was told quite explicitly by the current Rope maintainer that Rope does not intend to make it possible for a library using it to distinguish between bugs in Rope and problems in the source code Rope is analyzing.

I think it has a lot to do with emotions (mine and yours, I have apologized for my misspoke). In order to clarify my position (this seems to grown into pretty nice urban legend now) let me say three things:

  1. Rope is not meant as a replacement for flake8 with automatic replacement of discovered issues or anything of that sort. Certainly, we do code completion, but that's something else. And yes, presentation of the broken analyzed code could be better. Therefore, I don't consider it a bug when we don't fix the problems correctly, or when we do much else than noticing that there is an error.
  2. On the other hand, if somebody provides a good pull request for some kind of combination of flake8 incorporating it into rope (if it makes any sense, not sure about that; do we have to stuff all functionality into one package?) I am certainly willing to consider it.
  3. There are not enough good developers working on rope, it is not my main job and I have a hard time just to analyze pull requests coming. If you expect me to develop some complicated functionality (especially in areas which I don't think are really important for the further development of the project; py3k compatibility for example is quite different issue), then I will disappoint you.

Certainly I haven't said anything about closing issue reports without reading or any such stuff or not “to make it possible … to distinguish between bugs in Rope and problems in the source code Rope is analyzing” (not sure, what it even means).

@jorgenschaefer
Copy link
Owner Author

Therefore, I don't consider it a bug when we don't fix the problems correctly, or when we do much else than noticing that there is an error.

The problem I raised with you in that issue is that you do not distinguish between the error "invalid input" and "error in Rope".

I have not asked you to fix broken code, to be able to parse broken code, or to do anything at all except to raise some Rope error "hey, your code is broken, go away" instead of some random Python errors.

As long as you are unwilling to make that distinction, I am unwilling to support a library with such a broken API.

@mcepl
Copy link

mcepl commented Jan 29, 2016

I probably really just don't understand what you want? Could we get a pull request, or “Show me the code”, please?

@aligrudi
Copy link

Jorgen Schäfernotifications@github.com wrote:

Therefore, I don't consider it a bug when we don't fix the problems correctly, or when we do much else than noticing that there is an error.

The problem I raised with you in that issue is that you do not distinguish between the error "invalid input" and "error in Rope".

I have not asked you to fix broken code, to be able to parse broken code, or to do anything at all except to raise some Rope error "hey, your code is broken, go away" instead of some random Python errors.

If I remember correctly, rope raises
rope.base.exceptions.ModuleSyntaxError in rope.contrib.codeassist,
if it could not fix the syntax error itself. Is it not the
case now?

Ali

@jorgenschaefer
Copy link
Owner Author

I probably really just don't understand what you want? Could we get a pull request, or “Show me the code”, please?

As a user of the Rope library,
When I call a Rope API function, and the function raises an exception,
I want to know whether that was because the code I passed to the function was invalid
In order to tell the end-user of my program "hey, your code is broken", or "oops, sorry, there is a bug in Rope, please file a bug report".

Right now, the two cases are not distinguishable.

I am afraid I can not "show you the code" for an API contract.

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

No branches or pull requests

4 participants