Closed rye closed 10 years ago
I still would rather not have the scripts present at all in frecon
. They can go into our implementation without an issue, but it is dumb to have them in our API.
I do agree with your preference. This pull request exists merely to remove them from the root directory.
Then this pull request is fine, but I'd rather go a step further and remove them entirely.
I'd like to get feedback from @vmai or @tigerh. If we just want to remove them, then we can. I don't know; this seems like too low of a priority for me to be worrying about.
Mentioning them to get their feedback is all the worrying that is necessary.
On Sep 3, 2014, at 11:06 AM, Kristofer Rye notifications@github.com wrote:
I'd like to get feedback from @vmai or @tigerh. If we just want to remove them, then we can. I don't know; this seems like too low of a priority for me to be worrying about.
— Reply to this email directly or view it on GitHub.
I don't mind if you remove it or move it somewhere else.
I don't mind either way. If we do move it though, I'd say move it to the implementation.
So shall we remove them, @krye?
Since relocation (the point of this pull request) is okayed, I'll go ahead and merge this pull request. I've started work on the helper-script-files-more-dynamic
branch, but I'm okay with killing it off if we're just going to remove the helper script files in the end anyways.
Feel free to kill it off.
Per the comments on d166529be0ecad24f5f85867b687026362f053cf, I've decided to request to move these scripts to a 'contrib/' directory. The only disadvantage that I can see and that applies to people who use these scripts is that they have to use
contrib/run
andcontrib/update
instead of just./run
and./update
. However, this is more conventional; these scripts have no connection to FReCon, besides being an amenity for contributors.I plan to open more pull requests like this regarding changes to these scripts so that I can get feedback before they get merged. I don't want to make working on this project start sucking for people, but at the same time these scripts need to be more dynamic.