Have you tried using the logging module? Might be overkill for really small scripts as it requires a few lines to set up, but even the tiniest tool ends up requiring print-debugging at some point. With logging it works the same in 2/3, you can leave all the debugging statements in, and if a library also uses it then you get additional debug output from that too. Add a "debug" command line flag to pass when something goes wrong down the road (to change the default log level), and you don't have to add/remove statements for debugging.
For a vim extension - I use snipMate http://www.vim.org/scripts/script.php?script_id=2540 It's a bit on the dead side but works great as-is. ifmain followed by the expander key (shift-tab in my case) expands to the if __name__ ... idiom. You could add your own "p" snippet that expanded to print() in python code.
I have a small script in my ~/bin that pipes `info --subnodes "$@"` into less. That way I don't have to remember all the keys, and the whole output is like a big man page. Although on Debian and Ubuntu the info pages are usually not available by default anyway due to the "GNU docs are non-free"-decision Debian made a few years ago.
I disagree, and think they've done a great job. The CMake devs have always been really responsive to bigish projects that find CMake to be almost-but-not-quite good enough for their project, adding in missing autotools features or other semi-commonly used bits and bobs.
They manage to keep up with all the churn in the world of compiled software, whereas it would be so easy to let a tool like CMake bitrot. Old mistakes have sensible deprecation policies too, so they have managed to avoid the accumulation of cruft that could have brought it to a standstill.
You can speed it up somewhat by tweaking ~/.gradle/gradle.properties and adding org.gradle.daemon=true
and org.gradle.parallel=true. That way at least it doesn't have to re-read all the build files each time and will run some parts in parallel.
The benefit wrt the old Ant-based build is the way it lets you specify 3rd party dependencies. Being able to just add in say Timber, ButterKnife and Guava with a few lines of config, rather than downloading the jars, faffing with paths, making sure the pre-processing bits are in place, etc, is really a big benefit. Maybe Maven would have been a more sensible choice, since Gradle/Groovy seems pretty niche and not really used that much outside Android.
The FAQ is pretty clear about their reasons. It talks about tools, not other dependencies, but I'm sure the reasoning is the same: "Your project never works in isolation... To guarantee builds are reproducible even when we upgrade our workstations, we at Google check most of these tools into version control, including the toolchains and Bazel itself."
It's a sensible policy and one I use myself. Do you have a better reason for disliking this policy than a knee-jerk "yuck?"
Some reasons are the bloat, the possibility of "accidental" forks when a non-upstream version is compiled and checked-in binary-only, crufty old versions hanging around, and security problems. It adds extra work for downstream packagers having to pick it apart for distros.
Bundling gets particularly bloaty for git repos, since the history is always included in each clone. For perforce or SVN it doesn't matter so much as you only get the latest version of everything. In git each time there's a dependency update, it will pretty much add the size of the new jar to the .git directory. Over time it's going to grow huge. If at a later date the repository owner decides on a new policy where the third party files are not bundled, then even removing the directory from the current head doesn't shrink the repo size.
There are binaries in there for Mac, Linux and Windows (.exe file at least). You either need one or the other, not all at the same time.
This sort of thing is fine for proprietary software used in a controlled environment, but for open source it looks kludgy.
An alternative could be to have a "dependencies" repository that would be shallow-cloned as needed. At least that way the source code repo only would have source in it, not jars or executables. It'd ensure separation was enforced and you could still track requirements per version or change the policy later.
Tbh, if your company relies on this software, I would also make sure that it cannot just vanish - and thats the most efftive solution. Artifacts can disappear from the internet and you don't know if the downloaded stuff is still the same as before. Especially, if you look outside of the maven ecosystem, but even there you have to rely on apache and their partners. An outage can mean that you cannot deploy critical bugfixes to your platform.
This is true for Maven. The Maven repository project is very impressive and outstanding in its kind anyways. But leaving this great repository you are often on your own. Look at what happens to Google Code. How much stuff will be lost when its shut down? Hopefully nothing that you depend on. Its nice to have the binaries in a backup maybe but without access to the code, maintenance will be a nightmare.
Right... but this will be an anchor on adoption. I can see why e.g. the Android build system does the same thing since it's all off in its own world anyway. I doubt you'd be popular with Linux distro packagers if you required bazel for some C library.
One example - I use the ebay app on Android over the web site. It's miles better due to native integration. It remembers my login better than websites do (probably a security risk, but my phone's encrypted), it integrates photo-taking direct into the app which is handy for selling and buying e.g. buying: if you have a minor dispute with a seller you can just blast off a photo in the built-in messaging system. It sends notifications for watched items. The UI is also better than the mobile site - the click targets are nice and big and the lists scroll quickly - but that could possibly be improved in the site. The native integration is mostly what makes it nice.
Seems they no longer use this method. Instead they use `CHANGELOG merge=union` in a .gitattributes file at the root of the repository. That means that conflicting merges take changes from both sides of the conflict. It's what you usually want with a changelog.
Even if it is intentional, they'll still claim it's an unfortunate mistake and just backpedal from it if the pressure is high enough.
Edit: there really isn't a downside for Google. If no-one complains, then they get a clean shot at locking out a competitor. If they people complain loudly enough, they can just revert the change and pretend like it was a mistake. Within a week the whole episode will be forgotten and they can just cook up another scheme.