Live data from Hacker News

Write yourself a Git (2018)

wyag.thb.lt

21–30 of 111 posts

Re: Write yourself a Git (2018)

#21
post #9

I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)

I largely find argparse to be OK apart from a couple of issues.

First, it allows the user to abbreviate flags. They can pass --fl and it will be interpreted as --flag, assuming no other flag shares the same prefix.

This sucks for maintainability: add a new flag and any abbreviation for a previously existing flag that shares the same prefix will now stop working, breaking user workflows.

Since Python 3.5 there's the allow_abbrev parameter that allows disabling this behaviour, but then you also lose the ability to combine multiple single-character flags (so you can't pass e.g. '-Ev' any more, and would have to pass '-E -v' instead[1].

The other issue is that it's tedious to keep all the .add_argument calls readable, while maintaining a reasonable maximum line length.

[1]: https://bugs.python.org/issue26967

Re: Write yourself a Git (2018)

#22
post #9

I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)

Reminds me of CherryPy. An object oriented app can become a web server with a few function decorators (to make them public endpoints). Coincidentally still my favorite Python web framework.

https://cherrypy.org/

Re: Write yourself a Git (2018)

#24
post #12
post #9

I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)

Python Fire looks much more concise. But do you know of any other languages that handles argument parsing better then Python ?

Have you tried looking at docopt?

There are cases where it is not flexible enough but it is good for quick and dirty little scripts because:

* you use the docstring to generate the args. This way you always have a minimum usage that is valid

* Argument parsing is a bit more limited than doimg it yourself, but everything you usually need is there

* Docopt is exists not only for Python, but many other languages implemented it too.

Re: Write yourself a Git (2018)

#25
post #12
post #9

I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)

Python Fire looks much more concise. But do you know of any other languages that handles argument parsing better then Python ?

Perl has the problem of too many ways to do it. I like MooX::Options. Example here: https://metacpan.org/source/GETTY/AquariumHive-0.003/lib/App...

Re: Write yourself a Git (2018)

#26
post #9

I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)

docopt deserves a link in this thread: https://github.com/docopt/docopt

It’s a magical idea if you haven’t seen it. You just write the help text and it automatically creates the argument parsing code.

Re: Write yourself a Git (2018)

#27
post #9

I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)

For Java (or any other JVM language), nothing beats https://picocli.info/. Works well with GraalVM, too.

Re: Write yourself a Git (2018)

#29
I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again.

So I think: there must be a better way.

I have often thought about implementing a VCS. The idea behind one doesn't seem particularly complex to me (certainly it's simpler than programming languages). If I did I would quite probably use WYAG as a starting point. My first step would be to define the user's mental model -- i.e. what concepts they need to understand such that they can predict what the system will do. Then I would build a web-based UI that presents the status of the system to the user in terms of that model.

Re: Write yourself a Git (2018)

#30

I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again. So I think: there must be a better way. I have often thought about implementing a VCS. The idea behind one doesn't…

I'm like you. I use SourceTree to get a 'visual grasp' on what I find to be the noise of git commands. However, if you're into command line, you can try fossil: it's got lots going for it.

Your idea of a "user's mental model" might land you into trouble though, because all of us come from different backgrounds (subversion, SSafe, git, HG...) and they all maddeningly redefine terms in different ways (eg branch, forks, commits, checkout).

Post reply on HN