On reviewing the chocolatey packages available, I came across a few that have two (or sometimes more) packages apparently for the same product. At first glance is not possible to tell the difference.
For example, there is the AutohotKey package, and then there is also an Autohotkey.install package.
What is the difference between both types of packages?
Have a look at the FAQ in the Chocolatey wiki here:
https://docs.chocolatey.org/en-us/faqs#what-is-the-difference-between-packages-no-suffix-as-compared-to.install.portable
Quoting from that article:
tl;dr: Nearly 100% of the time, the package with no suffix (autohotkey in this example) is going to ensure the *.install. The package without the suffix is for both discoverability and for other packages to take a dependency on.
Chocolatey has the concept of virtual packages (coming) and meta packages. Virtual packages are packages that represent other packages when used as a dependency. Metapackages are packages that only exist to provide a grouping of dependencies.
A package with no suffix that is surrounded by packages with suffixes is to provide a virtual package. So in the case of git, git.install, and git.commandline (deprecated for .portable) – git is that virtual package (currently it is really just a metapackage until the virtual packages feature is complete). That means that other packages could depend on it and you could have either git.install or git.portable installed and you would meet the dependency of having git installed. That keeps Chocolatey from trying to install something that already meets the dependency requirement for a package.
Talking specifically about the *.install package suffix – those are for the packages that have a native installer that they have bundled or they download and run.
NOTE: the suffix *.app has been used previously to mean the same as *.install. But the *.app suffix is now deprecated and should not be used for new packages.
The *.portable packages are the packages that will usually result in an executable on your path somewhere but do not get installed onto the system (Add/Remove Programs). Previously the suffixes *.tool and *.commandline have been used to refer to the same type of packages.
NOTE: now *.tool and *.commandline are deprecated and should not be used for new packages.
Want more information? See http://ferventcoder.com/archive/2012/02/25/chocolatey---guidance-on-packaging-apps-with-both-an-install.aspx
Setting up a new environment with choco recently and became curious about this too. Chocolatey seemingly created a dedicated documentation site and moved the FAQs there, updating link to:
https://docs.chocolatey.org/en-us/faqs#what-is-the-difference-between-packages-no-suffix-as-compared-to.install.portable
Related
When I try installing with command line:
composer self-update && composer create-project --prefer-dist cakephp/app my_app_name
I keep getting this message, which I didnt use to have, now which one is required, which one is not, do I have to download manually everytime?
cakephp/app suggests installing markstory/asset_compress (An asset compression plugin which provides file concatenation and a flexible filter system for preprocessing and minification.)
cakephp/app suggests installing dereuromark/cakephp-ide-helper (After baking your code, this keeps your annotations in sync with the code evolving from there on for maximum IDE and PHPStan compatibility.)
cakephp/app suggests installing phpunit/phpunit (Allows automated tests to be run without system-wide install.)
cakephp/cakephp suggests installing lib-ICU (The intl PHP library, to use Text::transliterate() or Text::slug())
symfony/console suggests installing symfony/event-dispatcher ()
symfony/console suggests installing symfony/lock ()
symfony/console suggests installing psr/log-implementation (For using the console logger)
m1/env suggests installing m1/vars (For loading of configs)
asm89/twig-cache-extension suggests installing psr/cache-implementation (To make use of PSR-6 cache implementation via PsrCacheAdapter.)
aptoma/twig-markdown suggests installing michelf/php-markdown (Original Markdown engine with MarkdownExtra.)
aptoma/twig-markdown suggests installing knplabs/github-api (Needed for using GitHub's Markdown engine provided through their API.)
ajgl/breakpoint-twig-extension suggests installing ext-xdebug (The Xdebug extension is required for the breakpoint to work)
ajgl/breakpoint-twig-extension suggests installing symfony/framework-bundle (The framework bundle to integrate the extension into Symfony)
ajgl/breakpoint-twig-extension suggests installing symfony/twig-bundle (The twig bundle to integrate the extension into Symfony)
psy/psysh suggests installing ext-pcntl (Enabling the PCNTL extension makes PsySH a lot happier :))
psy/psysh suggests installing ext-posix (If you have PCNTL, you'll want the POSIX extension as well.)
psy/psysh suggests installing ext-pdo-sqlite (The doc command requires SQLite to work.)
psy/psysh suggests installing hoa/console (A pure PHP readline implementation. You'll want this if your PHP install doesn't already support readline or libedit.)
These are only suggestions that may extend the functionality of already installed packages, but everything should work fine without them. For example monolog/monolog will suggest a couple of plugins that will allow logging into different backends. But monolog/monolog will work without them - you may not be able to log for example to Sentry, but monolog will still be usable without this feature.
So usually you can just ignore these suggestions. But you can take a few minutes to check what these suggested packages are actually doing - you can learn about new technologies and solutions that can make your app better and easier to maintain.
If you're really not interested in these suggestions, you can use --no-suggest switch to avoid displaying them on install/update/require:
composer install --no-suggest
I've installed another additional module for my app with bower. As project dependencies in bower.json were not very strict, and a lot of time passed since last update, bower updated a lot of packages to newer ones. There were a lot of changes, and incompatibility between packages was the reason for major app crash.
I never asked for this, not a good moment for total upgrade&debug. How can I just roll back to previous packages?
Original package sources are in .gitignore and built with grunt into one file (so I can't just revert the commit - as packages renewed by bower will be the same in the next build)
I couldn't find out the old package set which was OK for my app (as package sources with specific version numbers are in .gitignore) UPD: found versions in built file, see my answer
I couldn't find any information about sort of "bower package history" or "bower undo".
UPD: I solved the issue for myself and described the solution in the answer. But I'm really not sure it's a good way, and would be grateful for any kind of mentorship about the subject.
I solved the problem for myself by digging into incompatiblities showed by bower, and finding compromise package set. Main issues were between newest angular asked by some packages and angular-ui-bootsrap working with older versions only for that moment. Also there were some issues with other newest packages, which I downgraded and will solve later on. So I used bower install [PackageName]#=[SpecificPackageVersion] (can use --save here to save it to bower.json) for manually setting compromise packages.
At the moment I realized, that there were old package versions in license comment blocks in the previous commits of built file, so in order to have old working set of packages I could:
git checkout HEAD~1 to have old file, which was built with previous package set
grep (search) package names or license comments in it
bower install [PackageName]#=[OldWorkingPackageVersion] (can use --save to save it to bower.json)
git checkout [BranchName] to make HEAD back
Make build (with previous packages installed again)
However, I'm not sure it's a good solution, and would be grateful for any kind of clarification about the subject.
This question already has answers here:
How can I make multiple projects share node_modules directory?
(7 answers)
Closed 4 years ago.
I've installed most of the NPM modules globally with -g
However, I see that whenever I create a new app project (example: angular project) using Yeoman, I see that the npm modules get downloaded again and get installed in the local node_modules folder.
I consider that this is extremely wasteful that the same modules gets downloaded and copied for each new project. The size of each new project is then around 160MB.
Is there a way to download only the modules locally in the new project that are not already available in the global npm node_modules folder? Say, anyway to automatically create symbolic links from the local node_modules folder to the globally installed npm modules?
Is this possible? How to set it up?
This is actually by design. From the Node.js blog:
In general, the rule of thumb is:
1.If you’re installing something that you want to use in your program, using require('whatever'), then install it locally, at the root of your project.
2.If you’re installing something that you want to use in your shell, on the command line or something, install it globally, so that its binaries end up in your PATH environment variable.
it is important for you to install project dependencies locally, as you have no guarantee that what is installed globally on your machine may be available on the deployment machine. True, you may manage both machines, or they may in fact be the same machine, but that case is never guaranteed.
Also, it's not unusual for you to have projects which rely upon a specific version of an npm which you may have installed an update for globally, breaking the project that needed the older version. Isolation is a key to keeping projects functional.
if you REALLY need to only maintain one copy, you can use symlinks. npm link globalnpm
Install it globally, and then npm link coffee-script or npm link express (if you’re on a platform that supports symbolic links.) Then you only need to update the global copy to update all the symlinks as well.
Note that the symlink option is really only relevant for hand initialized projects; generators such as Yeoman will always use local, as they follow the grain.
There are workarounds, but this is intentional to avoid equivalent to DLL hell or specifically library versioning mismatch meltdown. Besides 160 MB is a tiny price to pay for this luxury. Discrete functioning bundles are much nicer to ship as a unit of goodness - trust me
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.