How do you do version control in Julia if you want to use it in a production environment. That is, most of the Julia packages and Julia itself have a 0.3.10 or similar version number, so you should be prepared for major interface changes in the (near) future, and especially when the first digit flips from 0 to 1.
My package status look something like this:
julia> Pkg.status()
4 required packages:
- DataFrames 0.6.9
- Gadfly 0.3.13
- Jewel 1.0.5
- Mongo 0.1.3
44 additional packages:
- ArrayViews 0.6.3
- BinDeps 0.3.15
- Calculus 0.1.10
- Codecs 0.1.4
- Color 0.4.7
- Compat 0.6.0
- Compose 0.3.13
- Contour 0.0.7
- DataArrays 0.2.17
- DataStructures 0.3.12
etc...
It is recommended that you use Pkg.update() often so you have the most recent patches on all your packages.
If you need to update a package because of these patches or you need to use a new feature, you may break your code and there may also be dependencies between various packages, too.
Julia may be a mature enough language that does not have serious version-control problems, but I feel the need to poll the opinion of Julia users about their experience.
In a production environment you should not be using Pkg.update() often, or at least not without testing in a non-production environment first. This is true for every packaging system, not just Julia.
For Julia in particular, I would also recommend establishing a set of versions that work for you, then use appropriate lower and upper bounds in your REQUIRE file.
For example, suppose JuMP 0.9.2 works well for me, as does Gadfly 0.4.2. I would probably do something like the following in ~/.julia/v0.3/REQUIRE:
JuMP 0.9.2 0.10
Gadfly 0.4.2 0.5
This way, if I run Pkg.update() I will get 0.9.3 and 0.4.3 if they come out, but I won't be automatically upgraded to JuMP 0.10. Of course, this only works if you trust package maintainers to use version numbers sensibly, which is a serious problem especially when they are pre-1.0.
The DeclarativePackages.jl package (https://github.com/rened/DeclarativePackages.jl) allows you to specify exactly which versions of each package you want to use for each project: it starts Julia with exactly those versions of those packages available. This sounds like it might be what you're looking for.
Related
Does anybody have any experience with defining the python version of boost-python when installing from vcpkg?
I'm trying to use OpenVDB's python interface, and while I can get it working with the default python39 boost library, I'm not able to figure out how to define which boost-python version to install with vcpkg, and/or don't know how to define the correct parameters for the cmake command line to specify a python version at that point.
The default library that boost uses is 3.9, but as I'm typically in Anaconda, and 3.9 is not a standard download, I wanted to hold the boost library to be 3.8 instead.
I've commented in the github issues for openvdb, https://github.com/AcademySoftwareFoundation/openvdb/issues/946
but as this is not an issue with that project, and more of a dependencies thing, I thought I'd ask here in case you seen this on your travels :)
Thanks in advance for your time.
Neil
I am considering upgrading go-github from v17.0.0+incompatible to v28
I notice some versions that go-github released has a +incompatible suffix, especially for the v1 category. What does that entail? I am guessing version with +incompatible are incompatible with the newer/older version?
In general, when updating a third party dependency, how can I know if upgrading to the newer version is safe? Do I just have to read through the change logs?
Go in general does not want you to use the same import path for multiple incompatible versions of a project. This is so that one dependency can use one major version of a module and another dependency can use another.
This syntax indicates that the repository is not using a suffix for their module paths for a non-v0, non-v1 version, and bypasses the logic in the module code that does semantic import versioning. The documentation about this functionality is available on the Go website.
Since going from one major version to another is a breaking change in semantic versioning, you'll need to determine out of band whether or not they're compatible. The +incompatible suffix doesn't implicitly denote this, but going from v17 to v28 does. So changelogs might be a good idea, or you could just update and run your tests if you're confident in your testsuite.
I wrote some code months ago testing different optimizations of a function. I've since updated my anaconda installations of scipy, numpy, etc. that the code uses. Now the functions have different speeds (some faster, some slower), despite using the same code.
Is there anyway to check what the previous version of scipy that was installed was so I can attempt to see if something in scipy changed affecting my code? I use anaconda for package management, so I'm not sure if there's some record of previously installed versions somewhere. In particular I'd like to check cKDTree and cdist to see if either has changed in any meaningful way since my last installed version.
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I have a nuspec file that builds a nuget-package. I would like to control the dependencies, where I allow a range of versions, but what to always install a spesific version.
Basically this (not valid syntax):
<dependency id="Microsoft.CrmSdk.CoreAssemblies" version="8.2.0.2" allowedVersions="6.0.0" />
I want the nuget to dependency to accept 6 or higer (up to 9), but always want it to install 8.2.0.2 as default.
If I had version="6.0.0", it would always install the 6 version?
Any tips?
It is possible to specify an accepted version range in a nuspec-file with a version-range syntax. Accepting every version with a major version between 6 and (including) 9 would be specified by [6.0.0, 10.0.0).
What I understand from your question is that you want to specify an accepted version range but you want to force a certain version to be installed. There is no way I know of to achieve this but I also don't see the requirement for it: By specifying an accepted version range, the nuspec-file specifies to which versions of the dependency packages this package is compatible with. Hence, all accepted versions should work.
Forcing a certain version to be installed contradicts this compatibility statement in my opinion. This sounds as if you want to achieve a different goal: To verify that a consistent version of a NuGet package is installed in an application. This, however, should be solved on the consuming side, i.e. the solution that installs the NuGet packages. Assume the nuspec-file defines a package A that accepts all versions [6.0.0, 10.0.0) from Microsoft.CrmSdk.CoreAssemblies, but the consuming solution should always use version 8.2.0.2. Then this version 8.2.0.2 should be installed there first and afterwards the current version of package A can be installed, finding its dependency to Microsoft.CrmSdk.CoreAssemblies already resolved.
To achieve a consistent consuming solution, we implement checks on the CI server that verify that every package is referenced in all projects in exactly one version. By this we get a consistent product while keeping the actual NuGet packages flexible to be used with a different version of dependency packages in other products.