Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rice 2.0: move away from source parsing and use a Ricefile? #47

Open
GeertJohan opened this issue Feb 3, 2015 · 7 comments
Open

rice 2.0: move away from source parsing and use a Ricefile? #47

GeertJohan opened this issue Feb 3, 2015 · 7 comments

Comments

@GeertJohan
Copy link
Owner

"Rice 2.0? But 1.0 hasn't even been released yet!?"
Correct. Please see #48 about that.

Dropping .go file source parsing
I've been thinking about this for a while now. The parsing of go source is a nice feature, but doesn't always work as expected:

const boxName = `someBox`
rice.FindBox(boxName) // will work in 'live' mode, but rice tool won't find this box so it isn't embedded/appended.

This can be solved by moving the configuration of boxes to a Ricefile; a config file in some human-readable format such as yaml. This also allows us to define more configuration parameters per box such as:

  • strategy: embed vs append (embed one box, append the other).
  • path different than box name

Ricefile should be located in main package for the binary, but can include boxes used in sub-packages.
Ricefile import other Ricefiles based on import path? This could make defining resources in packages a feasible reality.

This issue is a work in progress..

@GeertJohan
Copy link
Owner Author

The current rice tool cannot use build tags, another reason to move away from source analysis and towards a configuration file for boxes.

@burdges
Copy link

burdges commented Mar 26, 2015

Appears the current rice tool fails when multiple packages live in the same directory too.

@GeertJohan
Copy link
Owner Author

multiple packages in the same directory? That should never happen right? (maybe exceptionally when one package has -buildflag and the other has +buildflag). @burdges

@burdges
Copy link

burdges commented Mar 26, 2015

Appears not. At least, it does not happen where I once thought I'd seen it happen, thanks!

@cortesi
Copy link
Contributor

cortesi commented Oct 20, 2015

There's another reason to do this - FindBox calls in global scope will work until the user uses embed-go, at which point it will fail, since variables are initialized before the init() functions are called. This has already confused people, as in issue #67.

@boyvinall
Copy link
Contributor

boyvinall commented Nov 23, 2016

I just needed to implement the ability for rice to append boxes without access to source files. Only just noticed this issue after I've finished, sorry about that. I've implemented slightly differently ..

If you're in a directory that has only the box contents but no source, you can run this:

rice appendbox --exec <executable> -b <box1> [ -b <box2> ]

See boyvinall@appendbox

@JonathanTech
Copy link

@boyvinall I also came across this issue after having problems with source parsing. I implemented it similarly on the command line here - JonathanTech#1 . I added it as a separate command instead.

rice append-simple -b <box1> [-b <box2>] --exec <executable>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants