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

What about a config file? #20

Open
twidi opened this issue Oct 20, 2017 · 4 comments
Open

What about a config file? #20

twidi opened this issue Oct 20, 2017 · 4 comments

Comments

@twidi
Copy link

twidi commented Oct 20, 2017

I love the idea and tend to use raincoat in my recent work.

But sometimes the raincoat comment does not have any good place in the source code.

First, it is often too long (my last one is 136 chars).

Second, you force it to be in a .py file.

But for example, for prospector, I forked the lib with a new package on pypi, and in my documentation, I say to use this package. But there is no relevant .py file in my project where to put this.

So I had to create a raincoat_prospector.py file for this only reason, with simply a comment!

Yes, it may not be "wrong" to have a "raincoat.py" file in the project with all the needed comments.

But maybe a raincoat.cfg (or a [tools:raincoat] section in setup.cfg could be the good way to handle this kind of thing?

@ewjoachim
Copy link
Owner

Hello,
First, thanks for using this software :) It's still in early stage so I believe you're bound to find ways to improve the UX, and this issue is the living proof of that.

You're right about the line length. I've been trying to think about a good way to split it into several lines when needed, but I haven't found a convincing way yet, given I'm matching a regex. Given how complex it's getting, I think that if I want to make this any more complex, I'd better call grep from my code directly (but that woudn't be nice to non-unix users). I'm open to suggestions :)

You're also completely right for the .py limitation. It's only because of this line and it has actually no reason to be, but if we removed this line, you'd still have to create a file with comments in it, which is not really interesting given we could have this, as you state, in a proper config file (and we wouldn't have the grep issue anymore)

Thirdly, you made me realize I'm missing a usecase : finding changes in a whole package, not just a module. That should totally be a thing :)

Conclusion: You're absolutely right and I'll be delighted to remove these pain points quickly, we just need to find the best way to do so.

@twidi
Copy link
Author

twidi commented Oct 20, 2017

Note that limiting to .py in the current way of searching is actually a good thing. Do you imagine scanning every single file on a repository? I don't think it's a good idea :)

@ewjoachim
Copy link
Owner

But shouldn’t that be configurable ? What if you port a python function into a js lib and you want to use raincoat to know if the original python function is modified ?

@twidi
Copy link
Author

twidi commented Oct 20, 2017

I'm just saying that, actually, it's a good thing to limit, especially because it's not configurable :)

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

No branches or pull requests

2 participants