@leader21 said:
@Fjux
solved?
Yes, should i close the topic in any way?
if so: How?
@Fjux
we decided to not close any threats, but if an issue / threat has been solved it can be marked as “solved”.
for that, you’ll have to put [Solved]
in front of your headline text. just have a look above, i already did so
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebook
make it so !
Will do that if i have someting similar going!
New question:
i just found out that the librarys i was using were using the built in promise of NodeJS.
But the default nodeJS version of Pimatic runs on V10.xx and that does not support it yet.
Now i made a small test and forced those packages to use bluebird.
But as they are 2 seperate libs, i needed to add bluebird twice as an external library.
Which seems a bit over kill. i noticed that the pimatic framework makes it possible for a plugin to load the bluebird lib from Pimatic instead of having to install it per plugin.
Can i do something similar for librarys that do not depend on Pimatic?
@Fjux said:
Can i do something similar for librarys that do not depend on Pimatic?
Yes, you can! See promise-retryer, for example, which is used by pimatic-openweather plugin.
Promise = env.require 'bluebird'
PromiseRetryer = require('promise-retryer')(Promise)
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
@mwittig said:
@Fjux said:
Can i do something similar for librarys that do not depend on Pimatic?
Yes, you can! See promise-retryer, for example, which is used by pimatic-openweather plugin.
Promise = env.require 'bluebird' PromiseRetryer = require('promise-retryer')(Promise)
i don’t think i meant something like this.
i thought it was a bit overkill that every library i use needs to have its own Bluebird plugin in their own node_modules folder.
i was asking for a way to have 2 libraries share their bluebird module.
like the plugins of pimatic are doing (i think) through the env.require ‘bluebird’. As my own plugin does not need to have bluebird as pimatic already has it.
@Fjux said:
i was asking for a way to have 2 libraries share their bluebird module.
But this is exactly what it does. Pimatic-openweather shares its bluebird module (which it got passed in from pimatic via env object) with with promise-retryer. This way, promise-retryer does not depend on bluebird by a module dependency via package.json. Instead, the bluebird library is passed on to an initializer function (similar to env.require) of the promise-retryer module. If you want to pass multiple modules you can have look at the env implementation - https://github.com/pimatic/pimatic/blob/master/startup.coffee
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
@mwittig
I understood what it does for pimatic. which is great.
But my “problem” is this:
my Plugin, uses a Library. That library needs Promises (bluebird in our case because V0.10 does not have it integrated)
And that library is using another library that also needs Promises, and again the same case as above.
So this means:
and that seems a bit overkill but i don’t see any other way to do it. As those libraries also need to work for other systems
@Fjux I don’t see any other short-term solution than forking all the dependents and make sure you pass-through bluebird downstream from pimatic.
May be you can convince the maintainers to address the backwards compatibilty issue (no native Promise implementation with node 10) and to adress the need of injecting a Promise implementation of choice in some scenarios. There is a library which appears to handle this - have a look at i-promise. See README section “Preferring user implementation over native” :
" … Default behavior is to always favor native implementation if found. You can still favor the implementation of your choice without overriding global Promise:
require('i-promise/config').use(MyPromiseImplementation);
NB: It is possible to inject dependencies at runtime - see “rewire” for example, but I won’t recommend this for production code, It is mainly for testing purposes if you need to replace parts of the implementation with mockups.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
Yeah thats to bad.
Will keep it like it is now!