I am using conan 2.0 and in the .conan2.0 folder there is no conan.conf file. Is it removed from Conan2.0?
Conan 2.0 no longer uses conan.conf, but only the new global.conf, which is already available too in 1.X. Also the legacy conan.conf used environment variables, while the new conf system uses self.conf.get() in recipes to get values, and conan config list can display the existing built-in configuration items (all of this available in 1.X)
Related
I tried reading the documentation but it's not so clear what the goal of this file is. I understand that the Profile defines a set of settings (OS, arch, etc.) used by Conan when a specific client installs packages, but what is the functionality of this settings.yml file?
It's well explained on settings.yml section, on Conan docs.
To summarize, settings.yml works like a template for Conan. Conan reads that file to validate which settings can be used. If you pass a build_type which is not listed in settings.yml, Conan will consider it invalid and raise an error.
It keeps a better pattern for all developers, you know everyone is using similar settings, no typo errors for instance. But you can customize your settings, adding new features, like new OS distro.
But probably you will need to share your settings with your cowokers, as now you have additional values, which is perfectly possible.
Regards.
I am trying to use the docker API for golang that is available from github.com/docker/docker/client. So far I am able to start the containers on the port that is predefined during image built. I am trying to map the port during runtime using the API; something equivalent to
docker run -p 8083:8082 -d myImage:1.0.0
I tried to do something like the following for mapping the ports:
host_config := &container.HostConfig{
PortBindings: nat.PortMap{
"8082/tcp": []nat.PortBinding{
{
HostIP: "0.0.0.0",
HostPort: "8983",
},
},
},
}
The problem here is that the variable "nat" lives inside the vendor folder of the API. I couldn't import something directly from the go vendor folder. Someone on the stackoverflow suggested to copy the go-connection folder into the github folder and remove the nested vendor directory. I did as suggested and created a path as follows:
"github.com/docker/go-connections/nat"
now I get the following error during compile time:
src\main\createcontainer1.go:53: cannot use "github.com/docker/go-connections/nat".PortSet literal (type "github.com/docker/go-connections/nat".PortSet) as type "github.com/docker/docker/vendor/github.com/docker/go-connections/nat".PortSet in field value
src\main\createcontainer1.go:65: cannot use "github.com/docker/go-connections/nat".PortMap literal (type "github.com/docker/go-connections/nat".PortMap) as type "github.com/docker/docker/vendor/github.com/docker/go-connections/nat".PortMap in field value
Have anyone faced this issue and overcome it? I am using the Go ver 1.8.
So you need to do more than just copy it, you need to move it. The same package located in two different locations are different packages to the go tool (because it can't guarantee they are identical, so it uses fully-qualified import paths).
If a package you're using has a vendor directory, and you need to use the packages in it, you have two options:
Move everything out of the vendor directory in that package into your $GOPATH/src
Vendor the package itself, and then move everything from the package's vendor directory into your project's vendor directory (<project root>/vendor). This is known as "flattening" your vendored dependencies, and most Go vendoring utilities (ex. Govendor or Godep) can do this, either automatically or with a flag. You can also do it manually, though.
The latter is generally the recommended strategy. The important key, though, is that the package itself cannot have a version of that library in its own vendor directory, as Go tool automatically uses the deepest vendored version of a package that it can access.
I am trying to create a patch for my application. Implementing the example described here worked as expected. However, the files for each version are stored in separate directories. Version 1.0 files are in c:sample\1.0 and 1.1 files are in c:sample\1.1. If I move the files to a single location, create the 1.0 installer, modify the files, and create the 1.1 installer; wixmst output of torch contains no differences. When I run pyro I get:
warning PYRO1079 : The cabinet 'media1.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet.
This is a problem for me because the files for my project are kept in a single git repository. We use branching and tagging to delineate versions. Because of this I only have one directory of files.
I have the .msi and .wixpdb for both versions.
How can I create my patch in this situation?
Pyro requires access to the .wixmst and the old and new files. If you only have one set of files (newer or older) then the patch will obviously find no file differences. That is why you are getting the error from Pyro.
If you use bindpaths to create the original .msi files (and their .wixpdbs) then you can provide the old paths using the -bt switch to pyro and the new paths to the -bu switch. If you didn't use bindpaths and you need to recreate the old directory structure for the old files and create a new directory structure for the new files.
If you can't get the old and new files to be found (bindpaths work best) then you'll have to do admin image type patching.
I am trying to understand the templating system. There is a /templating directory with following README:
It is not advised to make local modifications to those files after installation, as they might be lost during the installation of a new Trac version.
As an alternative, you can copy the templates you want to modify and place them in the templates/ directory of your Trac environment or in the location specified in the trac.ini file under the [inherit] templates_dir setting (the former having precedence over the latter).
This would be nice - I could have templates for my project nicely separated in the same path as my project. But this directory contains only part of the templates and for example ticket templates modification is impossible within this path.
So what is the correct way to modify Trac templates?
Thanks!
It is discouraged in general, because local/custom templates take precedence, and this could come in the way, if upstream releases have significant changes. You'll never get warned about a changed template and you'll have to re-base your template customization on-top of each new template.
Anyway, start from a fresh template copy from source. Templates are to be found in sub-directories templates of the respective Trac realm (i.e. ticket/templates, versioncontrol/templates, wiki/templates) and put it to all directly into <env>/templates (initially empty) or for reusing them in multiple Trac environments as per your [inherit] configuration.
Since Trac-0.11 Trac uses the Genshi template engine. See it's own wiki documentation about the available syntax.
We're having problems when trying to deploy a number of projects which use zc.buildout - specifically we're finding that they want to put their PYTHON_EGG_CACHE directories all over the show. We'd like to somehow set this directory to one at the same level as the built-out project, where eggs can be found.
There is some mention online that this can be done for Plone projects, but is it possible to do this without Plone?
Are there some recipes that can set up an environment variable so we can set the PYTHON_EGG_CACHE executable files in ./bin?
The PYTHON_EGG_CACHE is only used for zipped eggs, your best bet is to have zc.buildout install all required eggs unzipped:
[buildout]
...
unzip = true
If your system python has zipped eggs installed that still require unzipping for resource access, and setting the PYTHON_EGG_CACHE in your scripts is your only option (as opposed to setting the environment variable for your user), you could try to use the initialization option of zc.recipe.egg to add arbitrary Python code to your scripts:
[a-part]
recipe = zc.recipe.egg
...
initialization =
import os
os.environ['PYTHON_EGG_CACHE'] = '/tmp/python_eggs'
I'm not sure what you mean. Three options that you normally have:
Buildout, by default, stores the eggs in a directory called eggs/ inside your buildout directory.
You can set the eggs-dir variable inside your buildout.cfg's [buildout] section to some directory. Just tell it where to place them.
You can also set that very same option in .buildout/defaults.cfg inside your home directory. That way you can set a default for all your projects. Handy for storing all your eggs in one place: that can save a lot of download time, for instance.
Does one of those (especially the last one) accomplish what you want?
And: don't muck around with eggs in the generated bin/* files. Let buldout pick the eggs, that's its purpose.