Why does
composer require symfony/symfony ~4.4
install Symfony 4.4.43 (as of 6 July 2022), and
composer require symfony/symfony ^4.4
installs Symfony 4.4.0 (not what I asked for), and
composer require symfony/symfony 4.4
installs Symfony 4.4.0 (sensible default), but
composer require symfony/symfony "^4.4"
installs the latest version of Symfony 4.4.43 (as it should)?
My platform is Windows 10, using the command prompt.
Why are the double quotes needed for Composer to recognise the ^ character?
Why are the double quotes needed for Composer to recognise the ^ character?
Because the ^ has special meaning on the command prompt, it (the caret "^") is the escape character WP on the Windows command prompt, mind:
My platform is Windows 10, using the command prompt.
Unfortunately the caret ^ has as well special meaning for the version constraint (compare Caret Version Range Composer as well as for NPM/YARN etc.) so the character needs to be escape as well.
One way to do this is to quote the value to remove the special meaning on the commandline and then it works as you have tried yourself already:
composer require symfony/symfony "^4.4"
So the shorter answer on windows is: Quote the version constrain in double quotes with composer require so that a potential caret ^ gets passed to the Composer command verbatim: "^4.4".
Btw. something similar is the case on a Linux command prompt, the tilde ~ character can have special meaning (path to the USERs HOME directory) when at the beginning of a command line argument. Here again quoting in double quotes prevents having the special meaning: "~4.4.0" (compare Tilde Version Range Composer).
Related
I am trying to run a python urllib2 script and getting this error:
InsecurePlatformWarning: A true SSLContext object is not available.
This prevents urllib3 from configuring SSL appropriately and may cause
certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
After googling the error the solution, on stack overflow is to download requests' security package:
pip install requests[security]
But when I run that I get the error...
zsh: no matches found: requests[security]
Anyone know why zsh isn't picking up this library, it installs/upgrades requests just fine, I don't know why this isn't working
I am running this on a Debian Server...
zsh uses square brackets for globbing / pattern matching.
That means that if you need to pass literal square brackets as an argument to a command, you either need to escape them or quote the argument like this:
pip install 'requests[security]'
If you want to disable globbing for the pip command permanently, you can do so by adding this to your ~/.zshrc:
alias pip='noglob pip'
https://sass-lang.com/install suggests the following installation method:
If you use the Homebrew package manager for Mac OS X or Linux, you can
install Dart Sass by running
brew install sass/sass/sass
Is there any special meaning to the /? Or is it simply a string of characters?
The slashes have meaning, they separate the name into three parts. See for example https://docs.brew.sh/Taps:
If you need a formula to be installed from a particular tap, you can
use fully qualified names to refer to them.
The first two parts are assumed to be a GitHub user/org and repo. The repo is prefixed with homebrew-, taking us to the tap: https://github.com/sass/homebrew-sass.
The third is the specific formula to install from that tap, sass.rb.
I'm trying to figure out if it's possible that a bug I'm experiencing could be related to the fact that I use rbenv but the rest of my team uses RVM.
What I've been trying to figure out is whether the executables created by rbenv/RVM for a specific Ruby are the same. If the Ruby version and gem versions are explicitly specified in the .ruby_version and Gemfile respectively, is it possible that rbenv and RVM interpret code differently or should I expect identical outcomes?
UPDATE. A description of the actual bug I'm experiencing was requested, so here it is.
Essentially, the project is using the dotenv gem (and dotenv-rails) to read a .env file in the root directory. Two of the values (a salt and an IV) are Base64 encoded strings that contain newline characters. At some point in the decoding process, an extra backslash is being added before each newline character, causing the decryption to fail. The problem is, the dotenv gem appears to be reading the file correctly (i.e. running Dotenv.load in Rails console shows the strings parsed correctly), so it's some other gem or extension deeper in the stack causing the problem. And we have yet to identify it.
Our quick fix was to gsub the doubly escaped newlines (similar to this foreman bug fix, but some members of the team don't want to merge it because they're convinced it's an environment problem caused by rbenv. I don't think this is the case, but am wondering if it's a possibility before I try uninstalling rbenv and switching to RVM, which I really don't want to do.
UPDATE #2. Problem solved!
I did end up switching to RVM, but to no avail. However it did end up being an environment issue.
It was because my default shell is zsh but most of my team uses bash, and we were using heroku local:run to spin up the local dev environment. heroku local:run, it turns out, uses your default shell environment. Even if you make the call from a different shell (such as bash). However both rails console and heroku local:run rails console use sh by default. And zsh was handling the import of the env vars differently than bash and sh.
No, the binaries compiled by rvm and rbenv are not the same, and they are not drop-in compatible. (e.g., you cannot compile ruby with rvm and then drop it into an existing rbenv setup) The compilation options provided to each are different, and the resulting files are handled differently.
That said, you should consider two ruby binaries of the same version that were compiled with the same options to be binary-compatible; that is, any Ruby code that runs through one binary should run the same way through the other binary, regardless of what platform they were compiled on, provided they were compiled with the same options and libraries.
For example, if rvm is compiled without OpenSSL support you will have no end of trouble when trying to use libraries that rely on cryptographic functions. Likewise with bad versions of readline.
You can conduct a very simple experiment to determine the problem: compile ruby with both on the same computer and run your experiment through both versions.
For the specific problem you have outlined (dotenv and extra linebreaks), pay attention to the difference between single quoted and double quoted strings, and how Ruby handles control characters in them. Ruby interprets escape sequences in double quoted strings only, so you can likely resolve your issue by ensuring your value is always single quoted.
I am somewhat new to chocolatey, having installed a few packages in the past on Windows 8, and I have come to like it.
I have noticed that chocolatey installs the packages in the default Windows program directory (i.e. "Program Files x86" or so). Maybe there is more to that that I am missing.
For the specific case of Ruby 2.1.5 and Ruby DevKit, I have a couple of questions:
How can I ensure I install the x64 versions of Ruby, and Ruby DevKit using chocolatey?
How can I set a custom installation directory from chocolatey?
I know there is some information about changing the install directory, but the arguments syntax are dependent on the install system used (if any) by the specific package being installed, in this case, Ruby & Ruby DevKit. I am yet to find what would be the CLI installation string for ruby and ruby devkit on windows. Any help is greatly appreciated. Thanks
Forewarning
Parts of Ruby, coming from *nix, do not like spaces. Gems is one of them. This is not a Chocolatey thing, just an FYI in case you DO run into issues once you put it into Program Files. It likely won't work there, so if you run into problems, move it somewhere else.
The installer also doesn't really update permissions if I recall correctly, so you are on your own to make sure your permissions are good so you can run it e.g. Program Files is Administrators writeable only, which you won't have unless you are running an administrative prompt (this is UAC, it removes you from the Administrators group in non-elevated processes).
Guarantee x64?
If you are on a 64-bit system and a package has x64 urls in it, you will get the 64-bit version of that software unless you specifically use -x86 to force the 32-bit version.
Looking at Ruby 2.1.5 package files - we see the chocolateyInstall.ps1 has this line (note the $url64, so we are good):
Install-ChocolateyPackage "$packageId" 'exe' "$silentArgs" "$url" "$url64" -checksum $checksum -checksum64 $checksum64
Looking at Ruby2.DevKit package files - wee the chocolateyInstall.ps1 has this line (again using the x64 url):
Get-ChocolateyWebFile 'ruby2.devkit' "$file" -url "$url" -url64bit "$url64" -checksum "$checksum" -checksum64 "$checksum64" -checksumType "$checksumType"
Customize Install Folder
Usually you would pass the native switch for changing the directory through installargs. However these packages, due to the known issues above, use Chocolatey's Get-BinRoot to determine where to install themselves.
Chocolatey's Get-BinRoot
Get-BinRoot uses an environment variable named ChocolateyBinRoot (set by default to $env:SystemDrive\tools) to determine where to put certain software that doesn't really qualify for Program Files. You can set that where ever you want, including Program Files folders and it will use that location instead.
Installing Ruby and DevKit for v2
choco install ruby -version 2.1.5
If in cmd.exe refreshenv otherwise close and reopen shell.
choco install ruby2.devkit (note the ruby2)
Check the config.yml in the DevKit folder to see if it picked up the ruby installation, otherwise set it and run ruby dk.rb install (you may need force) in the devkit folder to install it into ruby. For more info, please see DevKit.
If in cmd.exe refreshenv otherwise close and reopen shell.
Now I'd like to say you can install gems, but you still need to deal with updating the ssl certificate for rubygems.org. I have an example on vagrant-windows-puppet.
Done.
IntelliJ will not detect installed PHP even though it does exist and can be used from the command line. I have installed php via brew install php54. Below is a screenshot of my issue along with evidence that it does exist. I've tried clicking the refresh button many times, but it will not pick up the binary.
I just had the same problem. Through some hackery, I discovered it was due to some ansi escape sequences in my prompt. From your screenshot it looks like you might have the same or a similar issue.
Essentially, IntelliJ uses a php script to create an XML string out of some PHP configuration items, including $_SERVER. The $_SERVER superglobal contains environment variables and therefore picked up the escape character (0x1b) in the sequence. Since the escape character is invalid in XML, IntelliJ rejected the output and concluded the PHP interpreter was bad.
Once I removed the ansi sequences from my prompt, IntelliJ recognized the PHP interpreter right away.
Hope this helps.
I had the same issue, and it turned out my Homebrew install was severely out of date when I installed PHP. To fix it, I ran:
brew update && brew upgrade
With some quick help from jetbrains support, the latest EAP version fixed it for me: http://confluence.jetbrains.com/display/IDEADEV/IDEA+14+EAP
http://youtrack.jetbrains.com/issue/WI-23045
If you prefer to keep investigating the issue, see Chris' answer and search the idea.log for something like:
INFO - s.impl.stores.FileBasedStorage - Document was not loaded for $APP_CONFIG$/php.xml file is null
idea.log locations
I've just now come back to this after some time and it looks like the latest version IntelliJ works with PHP installed via Homebrew. So I'm going to mark this as resolved.