Ya, same here. There are easy ways to make it work but none that I can think of feel “right.” Though I do quite like the “Doggo way.” It does also mean shipping the demo with package but it’s not like it gets compiled into peoples’ apps or anything. And of course if you want multiple demos then it’s a pain.
sodapopcan
zachdaniel
Creator of Ash
Something that might be useful is that Mix.env() returns :prod when your package is compiled for use in a user’s application.
So
@dependency if Mix.env() == :prod do
{:package, "~> ..."}
else
{:package, path: "..."}
end
2
BartOtten
I awarded Zach the solution but….had to revert.
When ExampleApp uses this code, it will still always fetch MyLib from Hex, no?
0
zachdaniel
Creator of Ash
BartOtten
Question: did you see my Oscar quality presentation of the wrong solution pick? 
Gotta get some sleep now. Just came back very fast as my brain corrected me just before I catched sleep.
0
BartOtten
So far my top pick: Demo code in same repo (excluded from Hex package)
Pre:
- use demo app for integration test
- (major) 1 clone and easy hacking in both example as lib
- no split commits; no sync issues
——-
Also on the table: dotfile + env var
- Presence check a dotfile which is .gitignored. (Default). If available, use
path: …/my_lib - If env set and path exists, use path of env var. (Override)
- If env set and false: use Hex (Override)
Pre over only env variable:
- no need for an env-setter.
- no clobbering ~.profile etc.
- shell and terminal agnostic.
- Easy (un)set:
touch .local/rm .local.
Pre over only path check:
- can set set non-default path.
- can force Hex.
no env, no file == no possible path execution
1
BartOtten
sodapopcan
No, of course not! I have a problem with being either overly diplomatic or overly blunt. When I say “super edge case” that is my diplomatic way of saying: “this will definitely 100% absolutely for sure ruin someone’s day one day but if you don’t care about that one person then go ahead” (apparently I throw some passive aggression in there as well)
The dotfile is a decent approach since I’m realizing this problem can be summed up as: “Only compile this dep from source if it I’M the one working on it.” This is exactly the use-case for dotfiles. It’s simple to throw these instructions in a README or CONTRIBUTING doc for those looking to hack on your lib. I do still prefer collocation, though (seems you do as well!) and will be keeping it up in my own situation.
To clarify for those who didn’t look at Doggo, the example app lives in the root of the package alongside lib, priv, etc… ie, there’s no parent directory contained the two. I’m just making sure as I’ve been misunderstood more than a couple of times today. Blame Halloween? I dunno.
0
Nicodemus
OK, I’m convinced, and will probably switch to the dotfile solution instead of path existence check.
I considered colocation, but I have many different demos for my library and don’t want them all colocated. I’d rather keep them very closely to a “stock” mix phx.gen codebase for easier understanding by newbies.
0
frankdugan3
A further perk of the doggo approach that hasn’t been mentioned is that it makes it much easier to keep the demo in sync with the tag/ref/release of the library. It also encourages maintaining the demo. Almost every demo not included directly inside the library that I’ve tried ended up being broken after a surprisingly short period of time, as the maintenance of the demos tends to get deprioritized when in a separate repo.
Also, it’s totally possible to have multiple demos with the doggo approach. Just nest them or namespace them.
1