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

Support custom ENVs #1520

Closed
wants to merge 11 commits into from
Closed

Support custom ENVs #1520

wants to merge 11 commits into from

Conversation

dschmidt
Copy link
Contributor

Hey,

so I started trying to implement the proposal from https://gist.github.com/rwjblue/51f1df4b21a23466ae47
To make sure I understood it right and to show up my problems I'm submitting this in a really early hacky stage.

Instead of adding methods to the EmberApp object I created a config model that is passed to the respective configuration module.

See the corresponding config files here: https://github.com/dschmidt/ember-cli-sass-demo/tree/customenvs/config

Going to add my questions as comments to the code below

Best regards,
Dominik

var jshintedApp = jshintTrees(preprocessedApp, {
jshintrcPath: this.options.jshintrc.app,
jshintrcPath: config.get('hinting', 'js', 'app') || this.project.root,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we support ember's path support? get('hinting.js.app')

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had the same thought when writing that line! 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^^ get('hinting.js.app') would be great, but we can add it in a follow up PR

@stefanpenner
Copy link
Contributor

Scheint gut Bruder.
I like that you have separated the config object out

@dschmidt
Copy link
Contributor Author

My most important question before I proceed:
If I don't cache the config object where/how am I supposed to set/add defaults like for jshintrc above?

@dschmidt
Copy link
Contributor Author

ping @stefanpenner

@stefanpenner
Copy link
Contributor

@dschmidt thanks for the reminder I have been traveling. Will review this evening.

@stefanpenner
Copy link
Contributor

@dschmidt this looks fantastic, only tiny feedbacks^

I think for the first pass we can ignore the caching stuff, subsequent work and introduce this.

@rwjblue
Copy link
Member

rwjblue commented Aug 13, 2014

Looks good. Happy to defer the caching issue for now.

@stefanpenner
Copy link
Contributor

can I provide any help/feedback here (sorry I have been out of town with little time to provide feedback here)

@dschmidt
Copy link
Contributor Author

Yup, you can. I am pretty clueless about what's up with tests ... they are hanging for me and having odd issues that I really don't know how to debug.

So if you could walk me through debugging it, that would be rad. Currently I am still at the ownCloud sprint, but could work on it early next week.

@dschmidt
Copy link
Contributor Author

I'm still aware of this PR, just been travelling a lot last month and haven't got around to it. Will get back to it soon hopefully, sorry.

@stefanpenner
Copy link
Contributor

No worries im in the same boat

@stefanpenner
Copy link
Contributor

cc @lukemelia

@rwjblue
Copy link
Member

rwjblue commented Oct 2, 2014

Submitted #2164 to make adding additional environments (as either production or development styles) really simple.

@stefanpenner
Copy link
Contributor

I will attempt some time this Saturday to help get this to completion.

@joshsmith
Copy link

Thanks a lot @stefanpenner. While I know there's probably not much I can do, let me know if I can do anything to help.

@joshsmith
Copy link

And thanks for attempt at temporary fix @rwjblue.

@stefanpenner
Copy link
Contributor

@joshsmith if u can get that PR over the finish line that would be handy.

@soulcutter
Copy link

What still needs to be done? I was able to make the tests pass with a fairly trivial change from config/environment -> config/development in project-test, but it's a little hard for me to follow what might still need attention.

@jakecraige
Copy link
Member

I'm a bit late chiming in here but it's better late than never.

First, since we're in ember-land I think we should make this very ember like and pretty much clone Ember.get, Ember.set, Ember.setProperties API.

This also means config.get,config.set and config.isEnabled should use the . syntax to get/set properties. This allows for arbitrary nesting or properties which currently isn't allowed. It's fixed 2 levels deep right now. A real example of this that wouldn't work: config.isEnabled('ENV.EmberENV.FEATURES.query-params)`

My idea is the API look like:

config.set(keyPath, value);
config.get(keyPath);
config.isEnabled(keyPath);
config.setProperties(keyPath, hash);

Thoughts?

@stefanpenner
Copy link
Contributor

we still intend to solve this, but master has diverged pretty far. I am going to close this, but we will sort this out.

@raido
Copy link
Contributor

raido commented Sep 6, 2015

What's the status of this?

@Kuzirashi
Copy link

Status?

@trcarden
Copy link

@stefanpenner is there any update on this feature? We are trying to put our app up but we need staging environment support

@stefanpenner
Copy link
Contributor

Please use the existing 3 env. And configure those further with environment variables

@trcarden
Copy link

Ah, thats pretty obvious in retrospect. For others that come across this i found a decent SO post here to help: http://stackoverflow.com/questions/26403334/how-to-pass-api-keys-in-environment-variables-to-ember-cli-using-process-env @stefanpenner thank you!

@JoannaFalkowska
Copy link

JoannaFalkowska commented Nov 16, 2016

Two years later - is support for staging never going to be done? Documentation implies otherwise.

Honestly I just encountered this issue today and can't understand why isn't it added? Am I really supposed to pass variables from bash if I need them for staging, like the @trcarden post above suggests? I'm really lost. There was an issue opened to document it (#5400) but documentation was never done.

@nathanhammond
Copy link
Contributor

@zackthehuman can you paste in the snippet that you wrote?

@zackthehuman
Copy link

@nathanhammond I think this is what you're referring to.

I sometimes build my addon's dummy app in order to use it like a demo/api documentation. For certain reasons I am unable to use the production build, so I want to use the development build, but I need to override some settings when I'm building the "apidoc" mode.

// environment.js

if(process.argv.indexOf('--apidoc') !== -1) {
    console.log('This is an apidoc build so the environment settings will be adjusted.');
    ENV.locationType = 'hash';

    // We want to force the country code to be "us".
    ENV.i18n.requestIpCountryCode = 'us';
}

@meliborn
Copy link

meliborn commented Nov 25, 2016

Is there a better way how to add staging environment like production and development? I need to set API_HOST for each environment in my app, but I can't wait another 2 year for support this feature.

@nathanhammond
Copy link
Contributor

@meliborn See the comment above yours. That represents a semi-official recommendation for how to toggle different information on a per-build basis. You'd use that code and something like:

ember build -prod --api-host=asdfasdfasdf

@meliborn
Copy link

@nathanhammond wrong link?

@wayne-o
Copy link

wayne-o commented Nov 25, 2016 via email

@meliborn
Copy link

@wayne-o could you throw me an example please? Can't imagine how to use it without if-env block

@nathanhammond
Copy link
Contributor

@meliborn Corrected link. Literally the comment above yours provides a workaround you can use, and my comment demonstrates how you could use it.

@nathanhammond
Copy link
Contributor

Also, @meliborn

but I can't wait another 2 year for support this feature

This type of communication is not constructive in an open source community. This implies a demand. Our work on Ember is a labor of love. Very few of us are paid to work directly on Ember projects, and if we are those efforts are strongly directed by those who are paying. We're real human beings with hobbies and pastimes and friends and things we do other than this. We strive to be friendly and helpful in spite of this, but I wanted to provide a bit of feedback so you understand that it's frustrating and hurtful to read comments like that. We'd love infinite time to address all things. I assure you. But we must prioritize.

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

Successfully merging this pull request may close these issues.

None yet