Rachael Sexton

Documentation has (unofficially?) moved to jupyter book with #57 and #62, so presumably this is closable? :smiley:

Poetry handles virtual environment instantiation/updating itself, quite nicely, and plays well with e.g. conda environments if the developer/contributor prefers. It will solve dependencies in a really understandable way, with much...

Not quite: poetry is generally not installed by the users, only the developers/maintainers. It's a toolchain for assisting in library management, installation, and isolation from the rest of the machine....

@PhilipVinc @wesselb That's an interesting use of `extra` for dev dependencies. I would just point out that, while I can't really see a reason it wouldn't work fine, it seems...

@PhilipVinc all awesome points. I definitely agree w.r.t. v1.2 being new, and I actually didn't know about generic "groups" until yesterday! :sweat_smile: Dev-dependencies have been around since the ... beginning?...

[Pyro link](http://docs.pyro.ai/en/1.3.0/_modules/pyro/distributions/relaxed_straight_through.html) for the original implementation.

@fehiepsi I was originally only using HMC, though planning to test out SVI as well. As long as not having access to a backward pass doesn't preclude using NUTS for...

@fehiepsi much appreciated! I think I should update the model there to reflect som local changes, but primarily I think it makes more sense to pull the dirichlet out of...

Interesting tricks, thanks! Implementing them at the moment, though, I'm getting a `funsor`-related error: ``` ... ~/Documents/Code/pr/numpyro/numpyro/infer/util.py in initialize_model(rng_key, model, init_strategy, dynamic_args, model_args, model_kwargs) 397 398 if has_enumerate_support: --> 399...

hmmm different error now: ``` ... ~/Documents/Code/pr/numpyro/numpyro/infer/util.py in potential_energy(model, model_args, model_kwargs, params, enum) 153 substituted_model = substitute(model, substitute_fn=partial(_unconstrain_reparam, params)) 154 # no param is needed for log_density computation because we...