grc
grc copied to clipboard
garabik
PyPI submission
It would be nice to have a one-line installer without having to git clone (like there's brew install grc on OS X).
An old PyPI entry (1.0b4) is available for pip. A brewformulas.org entry is available, too, but has no version information.
Related pull requests: #32 Related issues: #33
So how does it look, is it published in PyPI, please? It looks like the grc package is something else and it doesn't very trustworthy. And it just crashes with an error right after it's installed.
I would really appreciate to have this package in PyPI, would it be possible, please?
OK, I didn't notice there's a package in the Debian repository, so it's even better than PyPI for me.
You actually don't need brew for this. There's no magic here, there's nothing to compile, it just makes directories and copies files.
curl -LO https://github.com/garabik/grc/archive/v1.11.3.tar.gz
tar -xzvf v1.11.3.tar.gz
cd grc-1.11.3
sudo ./install.sh
I would still suggest making a PyPI support request to get the "grc" name back for this project. It seems that the project currently holding that name - https://github.com/exhuma/grc - is abandoned as defined in PEP 541 so maybe it will be an easy win.
@gdubicki the user @exhuma has an email address listed at his profile: https://github.com/exhuma, can you contact him and ask if you can take over his PyPI name. Moreover he has some colorizer too. Maybe it's good to compare features and see if this GRC already fulfills his needs of if it should be merge in functionality.
👋
I'm fine with handing over the pypi package. I can pick another name for my package without a second thought. You can PM me via the mail address listed for the specifics.
@exhuma I noticed now, your GRC was inspired by this GRC.
Maybe you can summarize what makes your work different or what advantages it has over this one. Then maybe @garabik can review the changes and integrate them, so your fork might be integrated into this original GRC.
It has been a few years since I started the project. I think (if I recall correctly) the main reason for creating my project was because I didn't find a way to get in contact with the original author. Or I got a negative reply with my feature request. I don't remember what it was.
Another issue was to find a collaborative platform for code-exchange (like GitHub). Also, the ability to install directly via pip install.I see that the first commit in garabik/grc is from 2015 while mine is from 2011 so that certainly played a major role in my decision to create a new project. It was by no means intended as a way to "take over the namespace".
The feature that I was missing was the possibility to have different "contexts" when parsing. A "context" is introduced by a line matching a regex, and inside that context, new coloring rules are active. This is done in my configs using the push and pop keys in the config.
Because this needed a more complex configuration I picked something more structured. Back then both JSON and YAML were popular candidates. JSON would have been in the stdlib but it's cumbersome to write. YAML fit the use-case much better even though it meant pulling in an external lib (I initially wanted to keep it self-contained).
Having said all that, alone the fact of changing the config-format will make this difficult to integrate.
I reviewed my local repo and noticed a few unpushed commits where I planned to support the config format from garabik/grc as well. But I got side-tracked and worked on other projects in the meantime.
I think the first order of business is to hand over my pypi namespace. And then if you would really be interested in looking at my features we should do this outside of this thread (to keep things more on topic).
I could drop my github repo as well and fork yours to keep a saner (and more importantly less confusing) workflow.
nb: with the "gentle prod" I had through this thread, I noticed that I had some unpushed / WIP-changes in my repo. Those changes were a preparation to support the config format from garabik/grc but are still very much "work-in-progress". For transparency, I've pushed everything, including the half-baked stuff. I will put my current wok on hold until this issue has been resolved.
Any news on this? How would you like to do the hand-over of pypi? I'd like to make sure that I'm handing it off to the right person. I would prefer to discuss the details of how I'll be handing it over outside of a public channel like this one. So either drop me an e-mail, telegram message or twitter-pm.
And let's not get held up by my implementation. It's a major rewrite of the configuration system. It's independent of the pypi hand-over and should not hold us back.
Please get in touch so we can close this issue.
@exhuma : I think that what you need to do is to:
- rename your project in the code,
- publish it under a new name in PyPI,
These steps do now require coordination with anybody and actually you can benefit from some time passing before you proceed, as you can do some things to ensure that your users know about the change, like:
- add README info, propagate it in every channel that you may use to communicate with your users,
- release a new version that can f.e. just show a warning about a package rename or maybe even include the new package as a dependency for a semi-smooth migration, etc.
Only then you need to get in touch with @garabik and coordinate when you delete the old PyPI entry and @garabik push this project under the same name into PyPI, to prevent the name from getting squatted between those steps.
Sorry for ignoring this thread for some time, I was overwhelmed by other real life issues. Anyway, I would happily start publishing grc via PyPI - I could even select a different name, but if @exhuma renames his project, we spare users some unnecessary confusion.
Looking at that grc, integrating it would be quite difficult and not backward compatible, unfortunately.
@gdubicki I'll get on that right away
I don't see an option to rename the project on PyPI though, only to delete it. And I would like to prevent someone snatching it in the window where I delete it and when this project is uploaded. As @gdubicki mentioned.
All I really need for that is a PyPI user-name and I can add that user-name as collaboartor on PyPI. There is https://pypi.org/user/garabik/ but I would need confirmation from @garabik to make sure it's the correct. I'd also be fine to add any other maintainer from this here GitHub project to the PyPI project. As long as we can confirm authenticity.
A transitional package has been pushed to pypi. I would suggest waiting a week or two for it to propagate. While this might not cover users that rarely upgrade, it will at least cover new installs.
All I really need for that is a PyPI user-name and I can add that user-name as collaboartor on PyPI. There is https://pypi.org/user/garabik/ but I would need confirmation from @garabik to make sure it's the correct. I'd also be fine to add any other maintainer from this here GitHub project to the PyPI project. As long as we can confirm authenticity.
No, that is not correct - that account was made before (IIR) a big PyPI transition that invalidated the passwords and I've lost access to the e-mail account registered with it.
My current (and working) account is https://pypi.org/user/rg/
Invite is out. I've added you as maintainer. I would still ask you to wait for a bit untill you pull my releases to give users some grace-time. But like this you have the power to do so whenever you want ;)
I'm not sure if using the "epoch" from PEP-440 would make sense here. May be overkill.
off-topic: But this discussion has rekindled my motivation for this project. And was wondering if you would have me as a collaborator (instead of cooking my own soup). The main reasons I started my own "copy" were:
- At the time I did not find a way to reach out to @garabik and by extension could not find a way to submit pull requests
- I needed a feature to "switch" to different coloring rules after a specific pattern was encountered. For this reason, my "copy" has a "stack" of rules.
I have been writing Python since 2004 and still do so professionally (been programming since 1998, to some extent even since 1987 but that was more fiddling around than programming) so I could surely share some experience.
I do have strong opinions on some topics which may or may not align.
In case you have a communication channel for these kinds of discussions (and if you are interested) let me know and we can connect.
In case you have a communication channel for these kinds of discussions (and if you are interested) let me know and we can connect.
Yes, I am definitely interested - would e-mail be OK? Unfortunately, I am now rather swamped with work and cannot quite find any free time. grc is really showing its age (the original version was written in the era of python 1.x), and my immediate plans are to add include directive to the configuration, clean up some config files and then reorganize somewhat the relation between grc and grcat.
e-mail is OK.
I've actually started fooling around with a rewrite, and have implemented the hardest part (I think) already, which is the replacement of the regex-match-groups with the colors of the list. There is still much to do and I might run into unexpected surprises. I will continue on that implementation for my own personal interest.
I would propose that I will continue working on this while trying to be feature-complete with grc and once I have a first MVP you can have a look and let me know what you think. That way you don't need to invest too much time into it.
I myself have plenty of other things to do and work only a few hours on this each week so it will not advance suprt quickly. I'll let you know once the MVP is done.