in JSON configuration file for installing a package. I saw many people enlisted dependencies in 'require' section. And I read somewhere on the internet that said: "we don't need to specify dependencies for dependencies because those nested dependencies will all be taken care of by Composer". If that why we need to specify dependencies for the initial package (the first package we declare in JSON file). Composer also takes care of its dependencies, isn't it? :D.
Can some body point me out what's wrong with my thinking here?
Many thanks!
Edit:
Sorry if I'm asking this simple question. However, AFAK, Composer docs doesn't cover this one. I don't know why those guys down voted my question without any comments or explanations.
Your thinking probably isn't wrong, but without an example case one can only speculate on the reasons why the dependencies' dependencies have been included.
Related
I am new to Go and trying to create my first program. Following the various getting started & tutorials I create a new module, which for my purpose needs to have a dependency on this module:
github.com/timescale/promscale#0.6.2
My problem is that the module has dependencies that have not "properly adopted" the semantic versioning approach.
go list -e -m all
...
k8s.io/client-go v12.0.0+incompatible
...
reports 37 such modules... so contacting the module author to have them adopt SIV, as I have seen suggested, will not be an option.
Am I missing something, or should I simply completely give up on using modules for this new project?
Are Go modules really usable today given third party "incompatible" modules?
Yes.
Am I missing something
Maybe: This "+incompabtible" is not a sign of failure.
or should I simply completely give up on using modules for this new project?
No, of course not.
Thanks for the answers and comments, it seems that:
New project should use modules, +incompatible dependencies will come up but that is fine
This FAQ entry has it right, just read the first 2 lines and keep "Additional Details" for a rainy day
go list -m all won't behave as described in all the tutorials if +incompatible dependencies exist, it will choke on the first incompatible module instead.
go list -m -e all seems to work as expected.
If you are using Goland, using GOFLAGS=-e seems to make dependency resolution work despite +incompatible modules. This may well have side effects that I am not aware of.
I've never compiled a single kernel module. I would like to understand how to change the source of a kernel module, compile and install it on Debian SO.
Can someone illustrate the steps or tell me a tutorial about it?
Thank you and everyone.
This question is a bit confusing since a .ko file represents a kernel object. In other words, it has already been compiled.
To edit the module you would need the source code, most likely tun.c and some related files.
StackOverflow is more meant for specific questions to be answered, not a tutorial site. Please do some research about Linux modules and make an attempt to install the module yourself. Some good sites for beginners:
kernel.org
https://www.oreilly.com/library/view/linux-device-drivers/0596005903/
http://derekmolloy.ie/writing-a-linux-kernel-module-part-1-introduction/
The last of these is the least comprehensive, but quickest to get you up and running. Once you get to the point where you have detailed questions, post them here and you will get better help.
I am trying to use https://www.npmjs.com/package/braintree-web with Aurelia (using the aurelia-cli and RequireJS). I am stuck trying to get all the many dependencies to resolve.
To use 3rd party library in Aurelia the library must be defined in the aurelia.json file.
If I add "braintree-web" in that file then aurelia complains that "braintree-web" it requires the modules "american-express", "apple-pay" etc etc.
If I manually create the "american-express", "apple-pay" dependencies then each one also refers to "braintree-web/lib", and a bunch of other sub-directory dependencies.
In short I can't get the "braintree-web" module to load because I have to manually build all sub-dependencies and its too complex to get working.
As I state above, I am using requireJS, should these dependencies all resolve correctly?
Any ideas as to how I can get this working?
Thanks
If all dependencies is what you need, then with requirejs + aurelia-cli you'll have to declare all dependencies. There is an experimental version of the cli being developed which you can find here, where you won't have to declare any dependencies in aurelia.json anymore.
With webpack you also don't need to declare any dependencies by the way.
Do you really need everything though? The docs mention for example you could import just the client. Still looks like a whole heap of dependencies, but at least a lot less than importing the main index.js.
You could also just include their pre-bundled client which I believe is https://js.braintreegateway.com/web/3.32.1/js/client.min.js
On a side note, the person developing aforementioned experimental CLI is actually looking for people to test it with non-trivial apps. Me and several others have tried it with great results, so I can recommend you try it. If you could report back in the PR that would be really awesome.
I'd like to just pull the following package in using composer so it will be autoloaded, but can't figure out how (or if) that can be done:
https://code.google.com/p/freshbooks-php-library/
Is this possible, and if so, how?
I know the question is a little old, but I don't think you can include packages, archives or libraries without the target resource containing a (valid) composer.json in the project root.
However; Google has given me this repo https://github.com/Isinlor/freshbooks-php which would seem to do the trick.
If your writing a go command (not a package) that is large how do you layout its internals? I would love to have some utility packages etc but not have those exposed for anything except the command's code. If it's all in the same repo I don't see whats stopping someone from importing those internal use packages.
You might make your utility packages internal to your package — like this. This won't prevent anyone from using them but a) why would you care anyway? b) the package's structure would give a clear hint on that these "subpackages" are internal to the project.
The answer is simple (but most probably not what you'd like to hear): Do whatever you like and is allowed. Having utility packages living somewhere is perfectly fine, either in the same repo as a "sub-package" or in a different repo.
Regarding
I don't see whats stopping someone from importing those internal use packages
Why do you care? If the packages encapsulate distinct and usable functionalities someone might benefit from importing them. Keeping those function together with the command does not "protect" them in the sense of "nobody should be able to look at my code". Just make it clear in the docs that you'll feel free to do incompatible changes at any time. Go is not about preventing each and any stupidity and protecting the lazy and incapable ones who deliberately ignore any documentation from shooting their foot.