In my project, I have a dependency for which I want to support a wide range of versions, and I want to test each version. Do I need to make a test suite for each version of the dependency, or is there a way I can more easily automate the process of going through each version?
Command line parameters or some other kind of parameterization?
Thanks
Related
I started using Conan to handle my C++ code base and I do not understand if it offers a way to automatically increment a package version after uploading a release.
I am talking about something like npm postpublish hook script that I use to execute npm version patch: so I am always sure that after a release, I am working on a new version.
I there any command that updates version field inside my conanfile.py? Is it automatically callable after a deploy?
No, there is no auto-incrementing feature for conan. The main reason is that it is not clear that a conan upload necessarily means bumping the version. For example, you might run a conan create to create a x86 binary, then upload it. After that, you create a package binary, exactly with the same recipe and version, for 64bits, x86_64, and upload it.
You don't want to bump to a different version. So bumping the version is done explicitly in the recipe version field. It can also be skipped in the recipe, and just defined in the command line: conan create . pkg/version#user/channel, but it is up to the user to define the version.
A different feature would be the package "revisions". Those will assign a new, transparent revision for each recipe change or binary rebuild. It is an ongoing work, so it might take some time until it is there.
Recently I've been running into an issue and I'm not sure how to best resolve it. We have a very modular architecture on the front end. We write individual angular components, put them in different repo's, and then include them in other apps as they are required, built with webpack & included via NPM.
Recently I've run into issues where multiple versions of a module end up in the compiled /dist folder coming from different places such as:
Directly included in the App I'm working on
2x Indirectly included through a module that I included (see chart for details).
The reason different versions could be used is that at the time CodeA is written ModuleA may be at version 1, then at a later date CodeB is written which also uses ModuleA which is now at version 2.
Then CodeA and CodeB are included in CodeC and now you have a module name collision on ModuleA.
With this setup, I believe if the multiple modules by the same name are loaded, the last one to get loaded is going to be the code behind that module name. Meaning it will be the one to be used by all modules. So there's no guarantee that the most up-to-date version is will be used. This usually results in getting an error that a method on ModuleA by name XXX does not exist.
To make sure I'm running the latest version of the module I have to go in and manually update (npm install) and build with webpack (npm run build) each library and then push them all to Github. Then I have to npm install in my root app. This isn't always an easy thing to do as the individual libraries' code may need updated to use the latest version of the module in question.
I'm looking for a solution to this issue. I'm guessing a structural/organizational change that will help us to not get into this predicament. If you have any solutions/advice/articles I need to check out please share. Thanks!
I´m pretty new to gradle and currently there is question that bugs me. The situation appears as follows: Based on a bower technology stack I implemented an Angular App. The app as it is doesn't change nor has it to be built in any way since there are just static javascript and HTML pages. In my opinion the used versions of angular, bootstrap and other libraries should also stay the same due to compatibility of the single libraries so these files also shouldn't change. Is this a correct behavior or should I get at least the latest build of the used libraries version as I deploy the application?
Also less is used in the application. Is there a way to compile the CSS every time I run the gradle build file or should I deliver just the compiled and finished CSS file?
As a result I´m also not quite sure if it's recommended at all using gradle to deploy an "static" angular application.
I hope someone out there can help me to answer the questions above. As you can guess, I´m not very experienced at deploying of such angular applications since this is my first project with this kind of problem.
This goes for all package managers, not just gradle but npm, gem, nuget, maven, whatever.
Use static dependancy version numbers. Otherwise you will end up finding breaking dependencies in QA or Prod rather than production.
This means you need to be aware of security fixes in your dependencies.
When you need a feature or fix in a new version of your dependencies, unlock the versions, rebuild and test in dev. Re-lock the dependencies and send to QA for verification.
I'd love to use Pandoc in a utility I'm writing (C# console app) and I found this bindings project on GitHub, libpandoc and by extension, it's .NET bindings project, libpandoc-dotnet.
I wish the author had included the built DLL but I suppose he wanted to leave it open to future Pandoc versions.
I have no Haskell experience whatsoever, I just want the .NET bindings in the end. I'm trying to install the dependencies via cabal but I don't understand the error messages and a cursory search leads me to believe installing base is a no-no, so I'm not sure what to do.
C:\Development\Contrib\libpandoc>cabal install base-4.1.0.0
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: base (user goal)
rejecting: base-3.0.3.2, 3.0.3.1, 4.6.0.1, 4.6.0.0, 4.5.1.0/installed-7c8...,
4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1,
4.2.0.0 (global constraint requires ==4.1.0.0)
rejecting: base-4.1.0.0 (only already installed instances can be used)
rejecting: base-4.0.0.0 (global constraint requires ==4.1.0.0)
If a kind soul could even build the damn thing (fork it? upload it somewhere?) I'd love you forever. Alternatively, show me how to build it properly and I can handle it from there I think. Though now that I think about it, not sure I have a C compiler installed.
Update:
OK. So it all comes down to the fact that libpandoc is 3 years old and its dependencies are out of date. I had no luck trying to get all the old Haskell tools to install and work, I probably had no idea what I was doing. I got as far as installing some dependencies but some dependencies weren't versioned so I had to track each version specifically and I eventually gave up.
I then just updated the dependency versions for libpandoc itself and now I've got all the dependencies built and linked.
The only remaining issue is that libpandoc needs to be updated to work against the latest Pandoc release (1.10).
On my linux (Ubuntu 11.04) development machine. I often need to install libraries from source. This always causes problems for me because the package manager doesn't consider packages installed from source when it checks dependencies. This makes the package manager worthless to me since once I install one set of libs from source (especially if they are vital to the gnome environment i.e. gstreamer), I can never use it again without screwing up my entire distro with mixed dependencies. It seems to me that it would be relatively simple to check the dependencies with pkg-config without having to worry with the deb database. I don't mind writing a little code here. Does anyone have any ideas?
Alternatively, you should look into the equivs package, which is made exactly for the purpose of creating empty .debs that will make apt/dpkg think a certain package is installed when it isn't.
Grab the source package from Debian unstable and build a .deb from that using the developer tools. If you need an even newer upstream version, you can apply the .diff.gz part of the Debian source to an upstream tarball and get a build infrastructure that has good chances of working. If if doesn't, I'm sure the package maintainer would appreciate patches to make it work with the new upstream version.
Another option would be checkinstall. It creates a .deb package containing dependency information, but also you will be able to uninstall it via package management.