Closed brewster1134 closed 5 years ago
Haha, that's because I didn't fully understand private at the time -- lessons learned over the years. =)
Ok, so hey, that broke all the builds, so do you want to look into it further? It can't be merged in the current state, but I don't disagree with this directly.
Can you give me some background on why you want this change, and what it's intended to directly resolve?
If you run rails as a daemon (rails s -d
), taspoon doesn't run due to pathing issues. I believe things like pow and other similar tools run rack applications as daemons, so it might be a nice ability. This was quick attempt at resolving that that I made quite awhile ago so i am a bit fuzzy on the details, but if it something you would be interested in merging as a feature, i can look into writing some tests and getting the build to finish successfully... One issue though is I am planning a trip out of town for 6 weeks soon, so it may not be something i can look into right away :/
Let me know what you think!
That's fair, and I appreciate your explanation. Have you tried running teaspoon with a specified port via the CLI? This won't start a server internally and will look at the specified port to see if there's already a server running there (at least that's how the code reads in server.rb) -- try it and see if that works?
well it's not so much a port issue as it is with background processes. they don't have the same CWD context that you have running it from an explicit directory. using Rails.root
keeps everything self contained.
did you look into the failing tests at all? it may just be a single point of failure.
allows running teaspoon via rails daemon