I should have published the release candidate to the RC branch

[maresb]

Oops, I missed this: https://conda-forge.org/docs/maintainer/knowledge_base.html#creating-a-pre-release-build

Now the release candidate is the default version, sorry! I hope this is not a big deal. The difference simply bumps a few dependencies, but I'm not a Pyscaffold developer, so I can't judge the implications.

While it would be possible to mark the package as broken, this seems a bit drastic. @FlorianWilhelm, what do you think we should do? Would it be sufficient to modify the installation instructions on Github to pin to 4.0.0? (Unfortunately I don't think the instructions would propagate to PyPI.)

[FlorianWilhelm]

Hi @maresb, absolutely no problem, so no worries. Actually, I think it's a good solution. The only difference between v4.0 and v4.0.1rc1 is that it depends on configupdater 2.0 and a bugfix version pyscaffoldext-django (if installed with [all] modifier). So users installing PyScaffold with conda will have a running version now (in contrast to how it was before) and everything should be fine. Thanks again for your help. You are really huge support for @abravalheri and me as we both haven't set up conda packages on conda-forge before :-)

[maresb]

Moin @FlorianWilhelm, I actually just closed my pull request since I solved it with help from the conda-forge admins. Everything should now be in order.

BTW, will there be a video published from your Ka-TeX talk? I'd like to share it with colleagues.

[FlorianWilhelm]

Moin @maresb, thanks, but this also means that after the refresh people will pull again version 4.0 which will fail since it depends on configupdater < 2.0 which is not yet on conda-forge, right? If this is true, we should maybe release version 4.0.1 quite soon. What do you think @abravalheri?

There was no video recorded of my Ka-TeX talk but my blog post has the same information. If you also watch the awesome talk by @corriebar from whom I took the motivational example, then there is only one aspect missing where I explain why the Poisson distribution is often used for counts like in a demand forecast.

[maresb]

Ah, very good point! I think I can render ConfigUpdater v1.1.3 in a new feedstock branch, and we can use that.

Thanks for the links! My colleague was trying to implement SVI in PyMC3, so it's great to know that it's already available in NumPyro. (But we also have to deal with some discrepancies between MCMC and VI, of course it's complicated...)

Also your classical blog post on JupyterLab was truly formative for me in setting up my workflow set up as I transitioned into data science. Thanks for that! :)

[FlorianWilhelm]

Thank you!

In the last months also PyMC3 made huge progress and is catching up with NumPyro, maybe even exceeding. @twiecki is about to port my NumPyro Model for Demand Forecasting to PyMC3 and then we will have a direct comparison.

Thanks, great that you like my post. I always appreciate feedback.

[FlorianWilhelm]

One more thing came to my mind. If you want to you can create a PR in PyScaffold that adds your name to the list of contributors, i.e. AUTHORS.rst. By doing so Github would also list you as a contributor and credit where credit's due, you are supporting us a lot.

[maresb]

Thanks Florian for the authors credit, I appreciate it!

dsproject should get its own feedstock as soon as the conda-forge team approves the package, which they should since it passed tests, and pytests isn't obligatory.

I would like to add you as co-maintainer to all the pyscaffold-related feedstocks if you don't mind.

[FlorianWilhelm]

Thanks @maresb, yes, you can add me as co-maintainer. Thanks.