A lot of improvements #16
Conversation
And move blocks of class methods under `class << self`.
It can require installed version instead.
More info here: https://editorconfig.org/
Don't change the global `$LOAD_PATHS`.
And resolve their offenses.
|
@bhaberer thank you. Again: comments are welcome. And although it's a huge PR, I tried to separate into commits correctly. For better understanding. Also I still feel issues with dev-ops out of my hands, like CI change, so… I could try to take a "Collaborator" role if you wish. Maybe even a GH organization. Again: no pressure. I have such experience already with |
|
Yea I’m happy to have more help. I’ll look at this soon, I’m mostly
catching up on work commitments to get projects completed before the us
holiday, so it may be a few days. Let me know if there’s a pressing need to
get this reviewed and merged tho.
On Fri, Oct 28, 2022 at 12:03 PM Alexander Popov ***@***.***> wrote:
@bhaberer <https://github.com/bhaberer> thank you.
Again: comments are welcome. And although it's a huge PR, I tried to
separate into commits correctly. For better understanding.
Also I still feel issues with dev-ops out of my hands, like CI change, so…
I could try to take a "Contributor" role if you wish. Again: no pressure. I
have such experience already with r18n and filewatcher, for example. Just
want to "unload" you and actively support a lib in which I'm still
interested in.
—
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMELMY5HLTYCTHY666XCTWFQPQFANCNFSM6AAAAAARRKJAKY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
- Brian
|
No, not really. Gladly, we have an opportunity to use git forks as gems via Bundler, so… it's fine. :) Take your time. I'd glad to meet a new gem release, mostly after these changes, but it's not a hurry. |
|
Oh yea, I’ll def be cutting a new gem release assuming I merge it all. 👍
On Sat, Oct 29, 2022 at 3:29 PM Alexander Popov ***@***.***> wrote:
Let me know if there’s a pressing need to get this reviewed and merged tho.
No, not really. Gladly, we have an opportunity to use git forks as gems
via Bundler, so… it's fine. :)
Take your time. I'd glad to meet a new gem release, mostly after these
changes, but it's not a hurry.
—
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMELJ43G3GCNO77QENMFTWFWQM7ANCNFSM6AAAAAARRKJAKY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
- Brian
|
|
@bhaberer just a friendly reminder. 🤗 |
|
Happy holidays. Just another friendly reminder. 😔 |
|
Oh lord 😅😂 yes I’ll look over this soon, sorty it’s been a long year |
|
And holidays are over. As always, no offense or hurry. Just friendly. |
| @@ -0,0 +1,10 @@ | |||
| root = true | |||
There was a problem hiding this comment.
Little resistant to adding personal editor settings to the repo, even mine.
There was a problem hiding this comment.
You know, there are different levels of "editor settings" (convention): "team" (it can have several projects), "projects" (where we're), "personal".
And I respect any level of preferences, but was trying to introduce project-wide convention. To keep project's source code in one style (not to mix space-indentation with tabs, etc.)
If you're against it — I can remove. But in my practice it helps, not to specific maintainers or contributors, but to a project, and all its members (how to write code for the specific project despite personal preferences).
There was a problem hiding this comment.
Like an additional example:
I have personal taste in tab-indentation. Even in Ruby. But I don't enforce it. And I have a code editor plugin, which toggles my settings (indentation, line length / wrapping, encoding, etc.) to the specific open project.
I wish similar to everyone. You can write as you want, but in a single project we're all should stick together, with chosen rules.
There was a problem hiding this comment.
@AlexWayfer fair points; how about this, fine with leaving it if we bump the .editorconfig / rubocop line length to the current rubocop default of 120, everything else seems fairly reasonable for what I'd expect from a ruby ide.
There was a problem hiding this comment.
@AlexWayfer fair points; how about this, fine with leaving it if we bump the
.editorconfig/ rubocop line length to the current rubocop default of 120, everything else seems fairly reasonable for what I'd expect from a ruby ide.
What is "ruby ide"? I've been using Atom Editor, now I use Pulsar Editor. I can use VS Code — whatever.
You can open EditorConfig's site: https://editorconfig.org/#pre-installed
Some editors work with it "out-of-box", some requires (simple) plugins. Even RubyMine, Sublime, etc.
Again: if I have editor's setting for tab-indentation — I'd have problems with this project with 2-spaces indentation. Which I'm not against, this config is just a kind of automatization for project-to-project work.
The same for end-of-line chars between UNIX and Windows users on the same projects, etc. Nobody against Windows users or their end-line chars, we just should keep the same chars along the project.
Basically, I wanted to update Faraday to v2 and found a lot of unstaged changes. 😅
I'd like to publish them separately, but you maintain this gem too rarely (no offense) and I feel like they're bound.
So… mostly code-style improvements and edge-case (or even architectural, with
ResponseorHelpersfor example) fixes.Comments are welcome.