Fully agreed with @leifericf!
Dan has been privately providing me support without ever having to – and I’m very grateful. 
I’m pondering compiling some short Pow how-to-guides and propose them as PRs. When I get the time I’ll do it.
dimitarvp
danschultzer
Pow Core Team
Thanks for the kind words both of you!
In my last startup I needed a good user auth library, so I began working on Pow. The business didn’t work out, but I have been able to work full time on Pow since. I’ve been fortunate to be able to build several businesses on top of the open source work from thousands of developers, so I only feel it’s right that I contribute back.
I’ve yet to feel burned out, and I do enjoy helping out everyone. It also helps me identify issues and make Pow more ergonomic to work with (I feel too many libraries are missing this). All this work doesn’t pay the bills though so my time is getting more limited as I’m heading back into building new businesses 
14
blatyo
Conduit Core Team
I’ve started using Pow and PowAssent. Works pretty well so far. I also tend to dive into the source of the packages I use to understand them better.
I’ve got two pieces of constructive criticism. First, I notice that you tend to use pipelines a lot, which is fine. However, there are many cases where things can fail in your pipeline and you end up handling it by making the next command in the pipeline aware of the possibility of that failure. A better mechanism for this in my opinion is with, which I don’t see you using anywhere (though I may have missed some place). with allows you to short circuit a sequence of steps when there is a failure. Meaning subsequent steps don’t need to consider that failure.
The second, is that to customize a something like a changeset, you have the code define changeset/2 and pow_changeset/2 for example. Instead of defining pow_changeset/2, you can just do defoverridable changeset: 2. That allows the user of your library to define their own changeset/2 and call super to call the one your library defined.
danschultzer
Pow Core Team
Thank @blatyo!
I’m really happy to get some feedback for the code. That’s the only way to improve it 
Yeah, I can see with makes sense in some of the ecto changeset methods. I’ve never done anything with with, and have always preferred just using pipe operators because it’s easy for me to understand what happens step by step.
I would love to see some examples of code in Pow that can be made more concise using with!
That actually already happens. changeset/2 is defined, and can be overridden. You can take a look at the use macro here:
You can use super, but calling pow_changeset/2 method makes it more explicit. As you can read in the docs, there’s also a pow_extension_changeset/2 method since the extension modules are separated from the Pow core module.
I often try to think of how someone new to my codebase would understand it, and how to make the code as explicit as possible.
Best case would be to call something like Pow.Ecto.Schema.changeset/2 rather than using a method defined in the use macro, but if you look at the Pow.Ecto.Schema module you can see that due to compile time config it’s necessary to define these methods in the macro so Pow is ergonomic to work with.
Feel free to open any PR/issues on GitHub too
blatyo
Conduit Core Team
I guess I should have realized that since you can obviously override the changeset functions. It was just the fact that there were the pow_* functions that threw me off.
I did see yesterday when customizing routes, that you had used defoverride there as well. However, you chose not to create pow_* functions there. Perhaps the changeset situation would be more obvious if you suggest people write @impl true before their changeset:
@impl true
def changeset(...) do
blatyo
Conduit Core Team
with is still step by step. The difference is that you don’t need every subsequent step to be aware of the errors of the steps before them. I sometimes call it the happy case operator. Because it allows you to describe what should happen if nothing failed and then address the situation where things did fail later or pass off the error for something else to handle.
I’ll throw up a PR sometime this weekend.
Naumoski
Hello Dan,
I’ve followed your guide for implementing custom controllers but the confirmation email is not sent. When submitting registration on the default pow routes (/registraton), the confirmation email is sent successfully. Also when submitting to the custom registration controller the user is signed in without confirmation but works properly on the default pow controllers. I used exactly the same code you used in the referenced link above, is there something that needs to be added to the code so the mail can be sent or am I making other mistakes.
Thanks
danschultzer
Pow Core Team
When you use custom controllers you’ll have to implement any extension logic yourself (the example only shows how to do it for the create action on the session controller, but it needs to be implemented on any controller actions that signs in users): https://github.com/danschultzer/pow/blob/master/guides/CUSTOM_CONTROLLERS.md#further-customization
Unless you got a good reason for not using the default Pow controllers, I would recommend that you just use them instead of custom controllers.
danschultzer
Pow Core Team
Pow 1.0.8 released
Changelog: Github
Hex: https://hex.pm/packages/pow/1.0.8
Multitenancy
You can now easily pass repo opts for your multitenant app: pow/guides/MULTITENANCY.md at v1.0.8 · pow-auth/pow · GitHub
Custom mailer layout
It’s now possible to set a mailer layout similar to Phoenix controller layout: Pow.Phoenix.Mailer.Mail — Pow v1.0.8
Decoupling
Ecto/Plug/Phoenix modules already was very decoupled, but there was some specs that didn’t reflect that, as well as expectation for the changeset being an Ecto.Changeset struct. Now there’s a clearer separation.
Happy coding 
blatyo
Conduit Core Team
Is it possible to only use a session cookie for a session, without the need of a backend store?