1. 1

    I don’t exactly get what 3.0 adds, since Channels and Daphne existed for a while, and were part of the Django project.

    I wish they made the ORM fully async, but that would be too breaking of a change.

    1. 5

      If you meant in the sense that you were expecting more features from a major version bump then the version bump comes from their release cadence & deprecation policy (new since v2) which sees the major version bumped for the first version after every LTS release (which 2.2 was).

      But if that wasn’t what you meant, then this talk by Andrew Godwin (PyconAU, Aug ‘19) gives a much deeper description of what’s going on under the hood to pave way for more exciting async features. v3 is laying the foundations.

      1. 3

        Personally, the two things I’m excited about in this release are:

        • Exclusion constraints. So many things get easier to model and validate with them.
        • The support for choice enums. This seems like a small thing, but it’s really a huge quality-of-life improvement.

        Plus the end of the Python 2 compatibility shims, because that’s a reminder of how close I am to finally getting to write modern Python in the Django apps I distribute.

        1. 1

          Making the ORM fully async is also next to impossible without a herculean amount of work because all of the database libraries would have to be modified to support async as well.

          There’s a really good talk (by the creator of Daphne) that was given at DjangoCon this year (https://www.youtube.com/watch?v=d9BAUBEyFgM) about the challenges of retrofitting async-await into django and plans to get there.

          1. 5

            Zzzeek (the creator of SQLAlchemy) wrote a very detailed blog post a few years ago about how everyone thinks they want async for their ORM, but it’s really not that great of an idea:

            https://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/

            1. 3

              Making the ORM fully async is also next to impossible without a herculean amount of work because all of the database libraries would have to be modified to support async as well.

              Also, I’m not too sure if a fully async ORM would be worth the effort. Sure, it might be an improvement, but if your database queries are taking so much time that they need to be async’d, maybe it’s time to optimize some queries.

          1. 1

            Playing with a number of things, but mostly looking into Standard File and potentially implementing a similar API along with a simple todo app based on this framework.

            1. 2

              Started learning rust on a number of personal projects. The first was a simple todo app (meant more for learning basics), but now I’m on to trying to port my IRC bot to see how that goes.

              1. 9

                Fun stuff! I’ve been meaning to do a write-up on this but haven’t gotten around to it yet. I may not be a master, but I maintain a number of themes (base16, monokai-pro, and grayscale being my favorites).

                My config has gone through a number of revisions both in and out of org-mode, with evil-mode, with normal bindings, etc. This is where I’ve settled for the time being.

                https://github.com/belak/dotfiles/tree/master/emacs.d

                Advantages to a config in org-mode: everything is in one file, org is amazing, and it’s easy to leave comments in a format that allows for more than just text.

                Disadvantages: everything is in one file, completion and linting of code blocks has never worked quite right in org files for me, and it can be slower

                Here are a number of things I can recommend for every config:

                • use-package - this makes config much easier and is the reason separate files works for me. It makes it easy to separate packages into different blocks (the main advantage you get from org-mode blocks) and removes a lot of boilerplate often used to speed up config loading.
                • straight - this is an alternative to package.el. It’s at least worth looking into. I’m using it because it makes it a lot easier for me to maintain my own packages without having a manual cloning process.
                • ido, helm, or ivy/swiper - pick one of these. ido is built-in but there are lots of good packages that expand it. helm is a huge package that does a ton of awesome things and ivy is a lighter weight package that’s still fully featured. I prefer ido because it’s fairly minimal.
                • If you want code completion, company-mode is amazing. I’ve been moving away from this for performance reasons, but I may revisit it later.
                • flycheck does an amazing job with linting.
                • magit is the best git wrapper I’ve used… ever
                • projectile made project navigation super easy. I would strongly recommend this for anyone who sometimes works in multiple projects at a time.

                If you’re looking for a good config framework, there are a few really solid ones I’ve used in the past, but I’m picky so I don’t tend to use them:

                • doom-emacs is a well-maintained project built on a really solid base that gets tons of updates. This is evil-mode focused but recently had better emacs bindings submitted as well.
                • spacemacs is evil-mode focused, but also has emacs bindings. It’s tried and true.
                1. 4

                  I’ve tried spacemacs, although i like it, I think its too much magic. I would like to get my hands in and learn how to configure things myself.

                  Thanks for sharing your config. If you ever write a blogpost, please share it in the community!

                  1. 1

                    Thanks for grayscale. I’ve been using it exclusively for a long time.

                    1. 1

                      grayscale looks very zenburn’ish to me…

                      1. 1

                        Yep! I ended up using the zenburn colors as highlights. The general idea was taken from the original duo themes for atom where brighter colors are supposed to be “more important”, but even after that, there were still things like warnings, errors, diff colors, etc… so I went with the zenburn colors because I found they worked well with grayscale.

                  1. 2

                    This sounds perfect for me, I’ve always felt like my Gitea installation was overkill. I love the automatic repo creation. I’m having a bit of trouble getting it to run though:

                    GITDIR_BASE_DIR=/tmp/git ./go-git-dir
                    

                    This gives an error ‘Users directory does not exist’ before exiting.

                    1. 2

                      I added back implicit repo creation under an option (implicit_repos under options in config.yml). There’s been a pretty big rewrite and the code has been cleaned up substantially as well.

                      Hope this works for you! Let me know if you have any serious issues.

                      1. 1

                        Thank you so much, I’ve been too busy to try just yet, but I’m definitely going to replace my Gitea installation with this. I’ll be sure to let you know if there are any troubles!

                        1. 2

                          No worries! It’s gone through a few big rewrites and cleanups in the last week or so… but it’s getting closer to the point where I’d call it stable.

                          Just pushed about 1k lines of tests which validate a TON of things related to permissions… and I’ve got one more idea for cleaning up the code.

                          Thanks for following up! Definitely let me know if you have any issues.

                      2. 2

                        I actually moved to a slightly more explicit definition of repos in config.yml, but it’s still super lightweight (this lets the server be a little bit more picky with path definitions since I really don’t want someone cloning something to be able to escape the git dir). Maybe automatic creation could be an option to enable?

                        There’s a bit of a chicken vs the egg on initial setup - I’d be open to suggestions on how to fix that (maybe a simple command to do it). Easiest way to fix that is manually cloning /tmp/git/admin/admin and making a user in users/whoever.yml, adding that user to the admins group in config.yml and then pushing. After it’s running, you should be able to clone ssh://git@localhost:2222/admin and push to that.

                        1. 1

                          Thanks, I understand now. I had it in my head that I was supposed to create a ‘users’ directory directly under the base dir (I didn’t realise it was for config). But reading it again it all makes sense now. I love the project, keep it up. The automatic repo creation as an option would be nice, although I’m happy either way as it isn’t too difficult to add repos to the config either.

                      1. 1

                        I use zsh, but I’m one of the maintainers of prezto as well as my own mini framework called zsh-utils so I’m a bit biased.

                        I’m a big fan of zsh because it allows more customizability when compared to bash, but I would strongly recommend using something like zsh-utils (or any number of config frameworks) to reduce boilerplate and strange defaults.

                        1. 3

                          Hopefully getting go-gitdir to feature complete. It’s in a working state, but I’d like to bulletproof it a bit more and add in all the features I said I would.

                          There’s also a Halloween party with some friends I haven’t seen in a while and other smaller things.

                            1. 11

                              Care to elaborate? “Yikes” isn’t very constructive.

                              1. 0

                                No thanks

                            1. 3

                              Really cool stuff! I’ve been looking at building something like this in to go-gitdir or having some sort of frontend that can display repos but haven’t gotten around to it yet. I might have to play with this.

                              1. 2

                                Nice project! I wouldn’t be against adding support for the git-daemon-export-ok magic file or something similar if it could help you.

                              1. 3

                                Hopefully spending a bit of time cleaning up go-gitdir and making sure the code is more maintainable moving forward.

                                Also, jumping back into ruby and possibly rails with a new personal project.

                                1. 10

                                  Hey all, this is a project I’ve been working on and finally decided it was ready enough to show it to the public. The idea was just to build an SSH server for hosting repos which can be configured using git to show that something can be built that’s pretty solid and doesn’t depend on openssh. I’ve got a few more tweaks to make (namely following something similar to what gitolite does where a repo can only be used if it’s defined in the config).

                                  It’s based on my past work on the gliderlabs/ssh library, the Gitea SSH server, and some experiments with git2go.

                                  1. 2

                                    This is exactly what I’m looking for, thanks! If you need a help, please create issues with the need help label, I’ll help!

                                    1. 2

                                      I added a few issues if you’re interested in helping out. Right now my main goal is to add more tests, but there’s some functionality around user config files and org config files that’s currently missing.

                                  1. 1

                                    Does it only differ from regular ssh git repos in that the server doesn’t need openssh installed?

                                    1. 8

                                      The setup for most traditional setups is pretty complicated because it involves sharing an openssh instance, creating a git user to allow the user to log in, as well as a method of automatically generating (or hooking into) the authorized_keys file. The actual permission checking is traditionally done with a separate shell program. This is a lot of small pieces and if any one of them does something wrong, it’s easy for a user to get access to your server. There was a bug with bash a few years back where if a user could ssh in to your server, they could get a shell - stuff like this makes piggy backing off openssh really scarry. I think it makes more sense to keep users separate from local unix accounts.

                                      Also, because the ssh server and git server are coupled together, you can start doing interesting things - allow users to log in with their actual username, build custom commands to list repos the user has access to, maybe even enable 2fa.

                                    1. 3

                                      Off topic - I see you have some involvement with base16:

                                      https://github.com/chriskempson/base16

                                      I use that via Hugo => Hyde with 2 of my sites:

                                      https://github.com/spf13/hyde#themes

                                      so thanks!

                                      1. 3

                                        Nice! Yeah, I’ve been involved in base16 for a while. I actually maintain the base16-emacs themes and base16-builder-go because I like the idea of that project quite a bit.

                                        I also do a little bit of work with prezto, but as I don’t use that much any more, I haven’t been putting in as much time there.

                                        It’s always nice to hear about people using stuff I work on in the wild, even indirectly :)

                                      1. 2

                                        Experimenting with a gitolite replacement I’ve been writing in go with more batteries included, like an integrated ssh server. In theory once I’m finished it should be possible to deploy as a single service pointing to a directory with no additional infrastructure needed.

                                        1. 1

                                          Will it allow more than one SSH key per user?

                                          1. 1

                                            Hey, just posted the first version: https://lobste.rs/s/4nr3sx/go_git_dir_simple_git_hosting_with_built

                                            It’s got a ways to go until it’s finished, but I’m pretty happy with the result so far.

                                            1. 1

                                              Yep, that’s the plan! I’m also looking at making it possible for users to specify their own ssh keys, rather than forcing an admin to do it.

                                          1. 4

                                            The thing that’s frustrating to me on this is that audio editing is stuck in this weird place where it’s “pick two of three” between a good audio editor, plugin support, and reasonable price. I’m pretty much stuck on a Mac because of this - you can’t run most (maybe any) VSTs on Linux and I really don’t want to jump back into Windows for development.

                                            I personally haven’t had many issues with the upgrade… External monitors work fine, software can be installed from non-app store locations, hardware support has been fine, I haven’t had a need for tech support but I haven’t had any major issues yet, and the MBP with touchbar has enough ports (though someone posted a list below with a listing of all the Apple hardware and the number of ports which is really interesting).

                                            But maybe I’m a “condescending elitist hipster latte web site designers” who “will let you know in no uncertain terms that their system is the best”.

                                            At least in my opinion, each OS has its strengths:

                                            • Linux is good for configurability and because of this, it works well for development and servers because anything can be tweaked
                                            • Windows is good for gaming and enterprise software because of the hardware support and long support releases
                                            • MacOS is best if you are doing creative work, but can also work for development, though it isn’t as tweakable

                                            The parallels here are mildly entertaining even if I don’t agree with most of them, but there’s just as much trolling in this article as anything else.

                                            1. 1

                                              I use a combination of apps - personally I use Things for tracking actual items and I’ve been experimenting with templates in Day One, essentially having a morning checkin (what am I going to do), an evening checkin (what did you do today, is there anything I could have done better) and a new weekly retro (what should I start doing, what should I stop doing, and what should I keep doing).

                                              There are a plethora of similar apps - I think it’s just good to find one (or two) that works for you. I’d like to eventually build something, but that’s a ways away from being finished/ready.

                                              1. 24

                                                After working at Bitbucket in the past, I have conflicting feelings about this.

                                                I think the hg UI is cleaner, more intuitive, and consistent, but I also think the project itself has suffered from mismanagement and the refusal to pick a direction and move forward, as shown by the 3-4 different branch tooling mindsets and how hard it is to determine “best practices”.

                                                The git UI is a nightmare (simply think of how many things git checkout can do) with inconsistent commands and command line flags, but it’s stayed comparatively simple… and out of the box it works incredibly well.

                                                From a technical standpoint, I understand the desire of Bitbucket to drop support for hg (though I don’t think dropping it in the manner they are is good, particularly for open source projects, both legacy and current). The APIs that were written had to be purposefully limited because they had to support both hg and git, but both of them have different branching models (unless you’re using bookmarks, but then you have 2 types of branches with hg). Any optimizations need to be done separately for both git and hg. Plus, if you want to move to a different storage solution, it would need to be implemented for both git and hg.

                                                All of this adds up to what honestly makes plenty of business sense: there aren’t enough hg users to warrant the complexity and bugs introduced by supporting 2 VCSs.

                                                This is rambling on a bit more than I originally intended…

                                                In any sense, I like hg… I really do… but I don’t think there’s any surprise here.

                                                1. 12

                                                  simply think of how many things git checkout can do

                                                  Happily these issues are slowly being fixed.

                                                  1. 2

                                                    That’s awesome to see! Though that was just used as an example. These are tongue in cheek, but provide many more examples: http://stevelosh.com/blog/2013/04/git-koans/ In particular I find the Hobgoblin section the most interesting.

                                                  2. 4

                                                    I’m just hopeful that heptapod or sourcehut finally pick up. Not having a good place to host hg has been a big problem for many years; bb has been a bad hg storage location long before they came to this decision.

                                                    1. 1

                                                      I wanted to self-host sourcehut, both for hg support and for the email-focused workflow. But after looking at the installation instructions, I decided my time is too limited these days, and installed gitea and migrated my hg repositories to git. Unfortunate, because I do slightly prefer hg to git.

                                                      1. 4

                                                        These stories just make me sad. I wish people wouldn’t tell me how awful the Mercurial situation is and that this is why I can’t share hg repos with anyone anymore.

                                                        I, mean, I know you felt compelled for some reason to tell me how there was no hope, so I can’t tell you to not tell me that. I just wish you hadn’t.

                                                        1. 1

                                                          This seems to be similar to my situation as well - a while back I sent in a few patches to make it slightly easier to run (sharing a config file, I think logging config files) but they just sort of sat there until I was told they didn’t add enough value to be useful.

                                                          Additionally, when I asked if patches to add docker support would be accepted, I was told there was no interest by the lead developer and that running services like this wasn’t the use case for docker.

                                                          It’s a really interesting project, but after being shut down twice like that, I have very little desire to go back to it.

                                                      2. 1

                                                        To be honest it would have made a lot of sense for BB to pick bookmarks as its officially recommended branching model and encourage hg ‘branches’ to die out.

                                                        1. 4

                                                          It would have helped a lot if bitbucket had gone “all-in” with hg like Github did with git. Github defined pull requests, vaguely inspired by a git command of the same name that does something very different than how people think of a pull request now.

                                                          Atlassian instead, from the very beginning when they first bought Bitbucket from Atlassian, decided to start playing follow the leader and catching up with Github, down to watering down the greatest distinguishing feature Bitbucket had: it was Mercurial-only. Bitbucket could have been involved in Mercurial innovation, dedicate more than a single developer to integrating new and exciting workflows like Mercurial Evolve, but they never went all-in.

                                                          I am unhappy with Atlassian. Just like Github is mostly responsible for git to the point that a lot of people confuse the difference bettween git and github, Bitbucket’s lukewarm approach to Mercurial is the main reason its usage has fallen so drastically. When @belak laments that there are no Mercurial users, let me tell you: there were. Bitbucket just worked very hard to drive them all to git.

                                                          1. 3

                                                            I agree that Bitbucket’s lukewarm approach has not helped, but I don’t think it’s the main reason as you stated.

                                                            hg evolve is still an extension, multiple years later. Part of it is the half-in approach you mentioned, but part of it is that when something is an extension (and not even shipped with actual hg releases), there’s a level of confidence you don’t have in it.

                                                            Part of why Atlassian was hesitant to go all-in is because when suggestions, proposals, or even donations were made, it took months, sometimes years for anything at all to happen. Even when Sean went to sprints as a representative of Atlassian, this was still the case.

                                                            You’re welcome to blame Atlassian. I don’t think anything I have to say would change your mind anyway… but I think there’s a strong possibility that there were other factors that contributed more to hg’s fall in usage than Bitbucket.

                                                            1. 1

                                                              Git has also moved slowly… it’s been, what, 14 years and only this year did they finally do something about how complex git checkout is?

                                                              I don’t know so much about the relationship between github and git, but I don’t get the impression that the git devs had a very close relationship with Github and quickly accepted their collaboration. Maybe they did and that’s the difference.

                                                              Maybe you’re right and I’m just frustrated at the wrong thing. But I never liked how the first thing Atlassian did was add git support. To me that seems like they almost immediately conceded defeat on the Mercurial front. And with nowhere to host it, it becomes a self-fulfilling prophesy of lower number of users, less development involvement, slower changes.

                                                      1. 23

                                                        Getting married this weekend! After months of planning and a hellish year (for other reasons) in general, it’s finally happening!

                                                        Anyway, break time is over - back to the preparations I go.

                                                        1. 3

                                                          Mazel!

                                                          1. 2

                                                            Congratulations in advance!

                                                            1. 2

                                                              Congratulations! Been married 12 years and loving every minute of it.

                                                            1. 3

                                                              There’s a large lindy hop/swing dancing event (classes, competitions, live music and dancing) in Seattle this weekend called Camp Jitterbug. I’ll busy the whole weekend working on personal projects during the day and dancing at night.