By default, poetry creates the virtual environment outside the project root. On mac, for example, it creates it inside ~/Library/Caches/pypoetry.
However, I found the following recommendation:
# Configure poetry to create virtual environments inside the project's root directory
poetry config virtualenvs.in-project true
Also, poetry documentation itself points out these two options:
By default, poetry creates a virtual environment in
{cache-dir}/virtualenvs ({cache-dir}\virtualenvs on Windows). You can
change the cache-dir value by editing the poetry config. Additionally,
you can use the virtualenvs.in-project configuration variable to
create virtual environment within your project directory.
What are the benefits of creating the project virtual environment within your project directory or outside it?
If the virtual environment is inside your project, then everything's together. If you delete the project later on, then the virtual environment will be too. If the virtual environment is outside, then you need to remember to delete two directories. However, this is just a recommendation and there's no obligation to follow it.
Related
I have a project in which I use multiple python virtual environments. For each directory, I use one different virtual environment. Is it possible to configure this in order to not change environment manually each time I need to execute files in another dir?
Just to be more clear, if my workspace is like this:
dir1
file1.py
file2.py
dir2
file3.py
file4.py
I would like to link dir1 with virtual env venv1 and dir2 with venv2. This way, whenever I run file1.py or file2.py, it would automatically use venv1, and if I run file3.py or file4.py, it should use venv2.
I'm checking this link and my first thought is configuring it with a debugging launch file via the 'python' argument. The problem with this is that I should create multiple launch options and execute each python file in debug mode.
Is there any other way? Like using workspace setttings (json file) but for each subdirectory I have? Or maybe using the settings of the workspace with a custom variable that is changed based on the directory where I execute the python file?
I have EJBs deployed on several different servers, for different environments. I have many projects that use these EJBs. I usually just run my projects against the DEV server EJBs, but sometimes I need to run against the TEST or PROD environment EJBs. This necessitates having to comment out all of the DEV nodes in my jboss-client-ejb.properties file and uncomment all of the TEST nodes. But then if I forget to change them back, I may mess up some data if I run it later. What I would like to do is create a different runtime configuration for each environment, and have each runtime config use a different version of the jboss-client-ejb.properties. Is there a way to do this? If so how? I have looked at all of properties of a run configuration, and don't see anything helpful.
In eclipse preferences search for string variable substitution. Here create variables that point to multiple config files for each of your environments. Then create multiple run configurations and for each one (like dev or prod) add a program argument that points to your string variable defined in your preferences like this -DmyconfigFile={$MyDevPropertiesFilePath}, or you could hard code the config path and have multiple runtime configurations that use different config files. Key point here is create multiple runtime launch configurations for each environment and add the properties for each environment that point to the config file respective to each environment. This way you can easily select the launch menu and decide to run "dev" "prod" or whatever you name your multiple configurations. Trying to do this with one runtime configuration will cause pain as you say, because it is easy to forget to revert or change the config file you want to to use. Hope that helps. Also if you create a new workspace you can export your runtime configurations using the export wizard which is also helpful for passing on to other developers or putting in source control.
P.S Looking more at your question you wan to pass in the config file path as a program argument, you are correct there are no specific options for setting this file path. Using program arguments with multiple launch configurations.
Is there any way to configure ember-cli globally to use yarn on new projects? A ember new <project-name> should use yarn without providing --yarn flag.
Background information
Recent versions of ember-cli uses yarn if
a yarn.lock file is present in projects root or
if --yarn flag is provided.
Since there can't be a yarn.lock before creating a new project, --yarn flag has to be used always on ember new <project-name> if yarn should be used.
If I got it correctly, ember-cli uses yam for configuration by a .ember-cli file. But as far as I know, this one is also only available in a existing project and could not set global configuration.
Motivation
I could of course always remember to use --yarn flag on creating a new project, but often I forget about it and have to abort the command. I prefer yarn also on init cause it's a lot faster. Also if it's not used already on project generation, yarn.lock file is not part of the initial commit. It's simply annoying.
.ember-cli can be configured both globally and on a per-package basis
Global configuration is located in $HOME/.ember-cli
Ember CLI’s runtime is configurable via a file named .ember-cli. The
JSON-formatted file, which must be placed in your home directory, can
include any command-line options whose names must be in camel case
form
Project only changes will be located in /path/to/project/.ember-cli.
It is now also possible to override command line options by creating a
file in your app’s root directory called .ember-cli and placing
desired overrides in it.
Since you're wanting to have all newly created projects to use yarn, add the following to $HOME/.ember-cli
"yarn": true
I'm using NAnt to build an ASP.NET MVC project.
The NAnt script then creates a zip package, containing a deploy script and all the necessary files.
The deploy script backs up the current running website, sets up the newer version of the website and updates the DB.
This works fine for a single environment.
However, we're asked more and more to set up a Staging/Acceptance environment next to the production. These environments, of course, differ in file structure, DB server, config settings etc.
How can I best handle this in the deploy scripts? I don't want to create separate variables for each environment, distinguishable by name only.
Providing defaults and providing the variables in separate files seems more logical.
Does anyone have practical experiences with this?
Store the things that you think are likely to change between environments in config files.
Visual Studio can do the heavy lifting here if you like; you can create settings and specify default values from the Settings tab of a Visual Studio project's properties.
This will create the config file for you and provide strongly-typed access through Properties.Settings.Default.
As for handling multiple environments through your build, I've seen some people recommend maintaining multiple copies of the config files - one for each environment for example - and others recommend using nant to modify the config files during the build or deployment phase. You can use a property passed to nant on the command line (for example) to select which environment you are building (or deploying, depending on how you're doing it).
I don't recommend either of these approaches because:
They both require changes to your build to support new environments.
If you change a setting in a deployed environment and forget to update the build then the next deployment will reset the change (somewhat defeating the point of config settings).
If someone creates a new environment (lets say they want to explore issues arising from upgrading to a new version of SQL Server for example) and doesn't fancy creating all new config files in the build system, they might decide to just use an existing environment's settings. Let's say they choose to deploy using the live settings and forget to change something afterwards. Your new 'test' environment could now be pointing to live kit.
I create a copy of each config file (called web.config.example, for example) and comment out the settings within them (unless they have meaningful defaults). I check these in and have those deployed instead of the real web.config (that is, web.config is NOT deployed automatically. web.config.example is deployed as web.config.example.
The admin of the new environment will have to copy and rename the file to web.config and provide meaningful values). I also put all the calls to the settings behind my own wrapper class - if a mandatory setting is missing I throw an exception.
The build and my environments no longer depend on each other - one build can be deployed to any environment.
If a setting is missing (a new environment or a new setting in an existing environment) then you get a nice clear exception raised to tell the admin what to do.
Existing settings are not altered after an upgrade because only the .example files were updated. It's an admin task to compare the current settings with the latest example and revise if necessary.
To configure the deployment, you could put all the environmental settings (install paths, etc) into nant properties and move them into a separate file (settings.build for example) then use the nant include task to include that file at the top of your deployment file (deploy.build for example). You can then deploy a new version of deploy.build without overwriting your config changes as they are in settings.build. If a new property is introduced into deploy.build nant will fail with a nice message to tell you that you haven't set that property.
When I add a file to my setup deployment project, Visual Studio won't allow me to edit the "SourcePath" to resolve an environment variable like $(DLL_PATH). It adds the file with the source path on my local machine and builds fine locally. When the same project is built on another machine, it won't work unless that machine also has the exact same path to files needed.
I want the SourcePath to resolve the $(DLL_PATH) so as long as a machine has it defined correctly the MSI package will build fine.
Not sure about the subst, since I have no control over what the other build machine looks like. If I try to assign a known directory to a virtual drive, it could possibly fail right?
Your best bet is to use subst.exe or a junction point to create a virtual directory. See here for information on junction points. Subst.exe simply creates a virtual drive letter. Put all of the deployable files in some directory tree with well-defined, constanct sub-paths, and make the root of that tree a junction point or virtual drive.
Actually what I did was setup a script.cmd to run after my project output is built to copy the dependencies to a folder that is relative to the actual project folder from the declared $(DLL_PATH). The setup project actually uses relative paths to the project, not absolute ones. So this works no matter what the build machine looks like. Then a script to remove this folder at the end.