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.
Related
I am trying to run AppEngine Standard Environment inside PyCharm.
The problem is when I include Google App Engine SDK as part of External Libraries, but it contains multiple version of old libraries that somehow has higher priority than the library I have in my env folder.
Specifically, it is loading jinja2-2.6 which doesn't work for Python 3, even though I have jinja2-2.11.3 in my env/lib.
Pycharm does have a bit of issues with its library system as many users have reported before. To Adjust the version of your libraries in PyCharm you must access the interpreter options relating your python interpreter for your current project, you can access this option by searching in the menu Settings/Preferences or by pressing Ctrl+Alt+S
In this dialog you can view the packages available and their current running versions. You can update the version by clicking on the ▲ symbol next to the version. if you have trouble upgrading to a specific version you may need then you can alway remove a package by clicking on the "-" on the right hand side after clicking on the package you wish to remove. After removing the package you can add a new one by clicking on the "+" button right on top of the "-" button. Here you can search for the package you need and before installing a package, you can check the specific version checkbox to search for the version you require in the dropdown menu next to it.
This link contains images for what i'm explaining here.
Remember that these packages are taken directly from the pip so if you have errors using the interface you can always try to manually edit the packages (also described in the link).
To upgrade a specific package using pip for python3 you can use the following command:
pip3 install --upgrade PackageName
I was ordered to deliver an app in 2 versions : one demo/light (limitted features) the other full (all features). I have a boolean in code which tells which one is running. They both run as expected in the simulator or on a test device (iOS and Android).
Now I want to distribute them. So I read that it was possible with XCode to define different targets corresponding to the light / full versions and with Eclipse it was possible to define the base project as a library and then create 2 projects also corresponding to the light / full versions.
Before I start messing around with my app project, is there a recommended way to achieve my goal with CodenameOne maybe via build hints that would change the app name and the boolean inside the code depending on a build hint value ?
EDIT 19/09/2016 (working methodology)
Following Shai's advices here are the steps I followed to generate a light version based on the full one (in case someone encounters the same case) :
Under your IDE (Eclipse or whathever) copy and paste the base package in the src folder and rename it com.packageLIGHT.appName (simply append LIGHT to the package name, don't use underscore or space since it will be considered as an illegal character later by Apple)
=> So now in src folder you should have
src
|- com.packageLIGHT.appName
|- com.package.appName
Then in com.packageLIGHT.appName remove all files except MyApp.java (aka the main file). In this file add import com.package.myApp.*;
3.1. (ECLIPSE) In "Run/Run Configurations" menu copy the existing config and paste it as Simulator_MyAppLIGHT and in arguments change it to "com.packageLIGHT.myApp.MyApp".
3.2. (NETBEANS) The "Run/Set Project Configuration" does not seem to work as expected since any configuration that might be selected leads to the same default behaviour. However applying step 6. and running the project in the simulator afterward has the expected result.
Now you should be able to run both versions by running the different configurations.
For iOS (not sure if it is also needed for Android) you have to generate another pair of provisioning files. So move the existing ones in iosCerts/FULL and use CN1 wizard to generate the "light" version provisioning files where you'll adapt the package name to match "com.packageLIGHT.myApp". Store the generated files in iosCerts/LIGHT. There is no need to overwrite the existing certificates (more on certificate here).
Finally replace in "codenameone_settings.properties" the original package name with the "light" one for the lines codename1.ios.appid and codename1.packageName. Also change the iOS provisioning files to iosCerts/LIGHT or FULL depending of what you want to build.
Now when you send the Android / iOS build to CN1 server it will build either the "light" version or the full one depending on what package is written in "codenameone_settings.properties".
Please note : if at step 6. you get NullPointerException on build.xml on line 469 (android build) or 344 (iOS build) which deals with certPassword="${codename1.android.keystorePassword} (android build) or appid="${codename1.ios.appid}" (iOS build) and you're using CN1 plugin version 1.0.0 20160812 under Eclipse then Shai's comment below may be worth it
If you want 2 distinct versions of the same app then you need 2 distinct packages since the thing that defines the app uniquely in the store is the app package. There are two common ways to do it:
Place functionality in cn1lib and build two apps
Build one app and just swap the codenameone_settings.properties file
The first one should be pretty clear but might be a bit painful to work with as you can't run the cn1lib and might run into issues debugging it.
The second one is actually rather simple. Create the main version of the app then add the package to the demo version and copy the main file there.
To run the demo version just change the package in the IDE "run settings".
Copy your codenameone_settings.properties to a separate file and just replace all the regular package names to the demo package names. When you want to build the "demo" version replace the codenameone_settings.propeties files with one another, you can automate that with a script obviously.
Is there a way to see when a composer package has an available update that is higher than its composer.json requirement allows?
My composer.son file has require statements like this:
"require" : {
"components/bootstrap" : "~3.3.4",
"components/jquery" : "~1.11.2",
"erusev/parsedown" : "~1.5.2",
...
},
Imagine parsedown has just had a big jump in functionality, and moved to version 2.0.0. When I run a composer update, as expected, my app will not be updated to version 2.0.0 (if one existed). Is there a way I can see that 2.0.0 is available with a composer command?
I am worried I might miss some updates, because I have locked down my required versions so much, and hope there is some command or way to see all of the available updates for my composer packages.
Is there a way to see when a composer package has an available update that is higher than its composer.json requirement allows?
Yes, there is a way. It's basically the comparison of the defined version constraint in your composer.json with the version numbers of composer show for the specific package.
composer show --self
This shows you the output of composer.json of your project.
You get the defined version constraints.
Alternatively, just open composer.json.
composer show --installed
This shows you the resolved and installed versions.
composer show package/package
This shows you all available version numbers.
Sidenote: composer show erusev/parsedown says there is no v2.0.0 release, yet.
There isn't a table display for this, yet, but it's a nice feature request, because it eases project maintenance. But assembling the infos automatically is quite resource intensive, especially when there are a lot of packages.
+----------------------------------------------------------------------------------+
| package | defined constraint | current version | available versions |
------------------------------------------------------------------------------------
| erusev/parsedown | ~1.0 | 1.5.2 | dev-master, v1.5.2, ...|
+----------------------------------------------------------------------------------+
First I'd recommend relaxing your version requirements to only have tilde-two-numbers instead of three, and see how it goes. It will allow you to not only get patch updates, but also compatible feature updates.
Composer currently has no way to signal to you the presence of incompatible versions beyond the original package being flagged "abandoned". You have to monitor the release announcement of the packages you use manually, or you could try and see what happens if you add the next major version to the requirement: "erusev/parsedown" : "~1.5.2|~2.0"
This however looks strange if you haven't even tried to update to the latest 1.x version using "erusev/parsedown" :"^1.5.2". Note that the caret is a shortcut for ~1.5,>=1.5.2 for major versions >= 1 (major versions 0.x are handled more strictly).
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.