I'm not pulling my phone out every time I have to unlock my computer at work. If IT wants my work account to be secure they should change their policies.
As an actually unseasoned Python developer, would you be so kind as to explain why the problems you see are problems and their alternatives? Particularly the first two you note.
The call to logging.basicConfig happens at import time, which could cause issues in certain scenarios. For a one-off script, it's probably fine, but for a production app, you'd probably want to set up logging during app startup from whatever your main entry point is.
The Python standard library has a configparser module, which should be used instead of custom code. It's safer and easier than manual parsing. The standard library also has a tomllib module, which would be an even better option IMO.
Logging configuration is done at import time for "utils" module.
Imagine code like this:
main.py:
import logging
logging.basicConfig(...)
logging.info("foo") # uses above config
if __name__ == "__main__":
import utils # your config is overridden with the one in utils
logging.info("bar") # uses utils configuration
...
Or two "commands", one importing utils and another not: they would non-obviously use different logging configuration.
It gets even crazier: you could import utils to set the configuration, override it, but a second import would not re-set it, as module imports are cached.
Basically, don't do it and no unexpected, confusing behaviour anywhere.
As a non Python developer, what would be the use-case(s) for importing a module inside of the main function instead of importing it at the top of main.py with the others?
Since the entire evaluation and running is dynamic, you don't need to import (and thus evaluate) a module in certain branches.
Eg. that `if __name__` trick is used to allow a module to be both a runnable script and importable module.
Top it off with plenty of common libraries being dog-slow to import because they are doing some of the anti-pattern stuff too, and you end up executing a lot of code when you just want to import a single module.
Eg. I've seen large Python projects that take 75s just importing all the modules because they are listing imports at the top, and many are executing code during import — imagine wanting to run a simple unit test, and your test runner takes 75s just to get to the point where it can run that 0.01s test for your "quick" TDD iteration.
You can also look at Instagram's approach to solving this over at their engineering blog.
Same! So satisfying to just explore the world they built, to the point of me neglecting the actual story a lot of the time. Hell, I think the only reason I advanced the story was to unlock new dialog from the NPCs. I loved the whackiness of 'em.
Unfortunately, I think the lost enchantment is just a product of aging. Things I were so enthusiastic about as a child (videogames, particularly) no longer have the same appeal, despite my best efforts to reignite some passion. That said, I did put in a good chunk of playtime with the remaster and I was still having fun with it. Though, not to completion as my attention span for videogames has dwindled.
The problem is not bone density. Your bones are never going to break under your own weight unless there's something seriously wrong with you. The problem is joint health.
Sure, guess I read your comment as bone-focused. That said, joints also do get more resilient when resistance training. Although, I'm aware not necessarily at the same rate as the muscles themselves, leading to issues where the muscles are capable of handling more weight than the joints can happily handle (if we are to personify joints). But, I think that issue is mostly obviated with good programming and load management.
I'm starting to use `mise` for tooling management and task running on greenfield projects, myself. Anything you feel `just` does better with regards to running tasks?
The biggest advantage just has is that it's been around longer, in mise tasks only came out of experimental like a month ago. mise tasks themselves are stable, but there are still experimental things and some portions that need to be used more—like windows. That said, most of the stuff that needs polish are features just doesn't even have.
here's my unashamedly biased thoughts on why I like mise tasks compared to just:
* tool integration - this is the obvious benefit. If you run `mise run test` on CI or wherever it'll setup your toolchains and wire them up automatically
* parallel tasks - I saw this as table-stakes so it's been there since the very beginning
* flags+options - mise tasks are integrated with usage (https://usage.jdx.dev) which provides _very_ comprehensive CLI argument support. We're talking way more than things like flags and default options, as an example, you can even have mise tasks give you custom completion support so you can complete `mise run server --app=<tab><tab>`
* toml syntax - it's more verbose, but I think it's more obvious and easier to learn
* file sources/outputs - I suspect just doesn't want to implement this because it would make it more of a "build tool" and less of a "task runner". I chose to despite having the same position that mise tasks is also not a "build tool". Still, I think even in the world of running tasks you want to only run things if certain files changed often.
* `mise watch` - this is mostly just a simple wrapper around `watchexec -- mise run ...` for now, but it's an area of the codebase I plan to focus on sometime in the next few months. Still, even as a simple wrapper it's a nice convenience.
* "file tasks" - in mise you can define tasks just by being executable and in a directory like "./tasks". This is great for complex scripts since you don't also need to add them to mise.toml.
I have not used just very much, but I did go through the docs and there are a handful of things I like that it definitely does better:
* help customization - it looks like you can split tasks into separate sections which is nice, I don't have that
* invoking multiple recipes - I don't love how this is done in mise with `mise run task1 ::: task2` but I _also_ wanted to make it easy to pass arguments. At least for now, the ":::" won out in the design—but I don't like it. Probably too late to change it anyhow.
* [no-cd] flag - both just and mise run tasks in the directory they're defined, but I prefer how this is overridden in just vs mise.
* expression/substitutions - mise uses tera for templating, which is very flexible, but it requires a bit more verbosity. I like that in just you can just use backticks or reference vars with minimal syntax. Same thing with things like joining paths and coalescing. I have all of this, but the syntax is definitely more verbose in mise. Arguably though, mise's verbosity might be easier to read since it's more obvious what you're saying.
* confirmation - I love that in just you can just add `[confirm]` to get a confirmation dialog for the task. I'm sure we'll get around to this at some point, mise already has confirmation dialogs so it shouldn't be hard to add. The tricky part will be getting it to work right when running a bunch of stuff in parallel.
* task output - I haven't used just that much so I can't actually say that it's "better", but having more control over how tasks are output is definitely a weak part of mise right now and is in need of more functionality like in just how you can add/remove "@" to echo out the command that's running
I want to call out one very silly thing that from reading these github issues sounds crazy. It sounds like both just and taskfile have the same behavior with `.env` files. In just and taskfile, variables defined in .env are ignored if they're already defined. I don't think anyone would want that—nobody has asked for mise to behave that way—and it doesn't appear either tool even allows you to change it!
Hi Jeff, thanks for creating mise! I am gearing up to migrate from asdf, very excited to check it out. Not totally sure we can adopt mise for tasks (we use just) but willing to give it a whirl. Putting run commands into toml sounds like it might be challenging, I wonder if there's syntactic sugar that would help.
most people just put simple tasks into toml (like `npm run test` or something), for anything complex, file tasks are much better: https://mise.jdx.dev/tasks/file-tasks.html
file tasks are basically just a directory of bash (or whatever shebang) scripts, but special comments give them extra functionality like dependencies or defining flags/options.
> Pancake lens allow you to make smaller headsets and typically result in better image quality. The downside is they lose a lot of light so you need very bright screens.
A version, or two, ago they've introduced their own rating system where you can thumb's up/down certain criteria (which elude me, right now. but, of the "ambiance", "food quality", "service", etc. variety). So, I imagine they're looking to ween off of Yelp for their rating's system.
