On Mar 13, 2017 1:30 AM, "Jin Hsieh" <[email protected]> wrote:
But you could recognize the modification we made *is hard to upstream guys
to accept/merge the changes into their trunk*,
so many getenv("SNAP") in the code or in where the code flow uses
clean_env() we also need to cache the SNAP-related variables,
I am wondering if we have a better way to do this, for example an interface
or environment-sharing could make the life easier?
1. then have the chances to make the upstream code up without
getenv("SNAP") to make their code snap-adaptive
2. then have a much regular way to export environment when one
component calls another one externally without "export_environment" support
I'm not sure how an interface would help with the environment here. The
codebase would still need to use it. Maybe I'm missing something.
I hear you about the difficulty in upstreaming necessary changes, though. I
find it helps to not make it snap-specific. "Hey, these paths are
hard-coded. In my project I need them elsewhere. How would you feel about a
PR that adds support for more flexibility there?" Then instead of having
$SNAP everywhere, use something specific to the upstream project, like
$POSTFIX_CONFIG or something. That still works for your snap, but makes the
project feel more generally flexible as opposed to littered with code to
support snaps.
Kyle
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
