I am working on a Symfony 2.7 project. I ran composer update --dry-run to check which packages could need an update. Composer notified me about a deprecated package:
Package symfony/icu is abandoned, you should avoid using it. Use
symfony/intl instead.
I simply removed the dependency from the composer.json file and ran composer update --dry-run again. The message did not show up again, symfony/icu was uninstalled and symfony/intl was not installed.
Fine, this means that non of the other requirements depends on symfony/icu or symfony/intl. But can I be sure, that non of my own code requires any of these packages?
I created the project white a while ago and I do not remember why I added symfony/icu. I is possible, that the code that once required this packages has been removed, but I am not sure.
I used grep to search for any import of symfony/icu and found nothing. However that does not guarantee, that the package is not uses somewhere within my code, does it?
Is there any way to check if there are any dependencies within the complete Symfony project that require a specific package?
Check for every package? :(
I think you can do this only with automated testing.
There are no tools (I'm aware of) to detect whether some package is required to complete missing classes. There are also optional dependencies (package works without them, but with them will add some new features), so you will find missing classes but not required to run application.
How to check one package? :)
You heading right direction with grep. Yet rather look for namespace instead of package name. Package name is not always 1:1 to package namespace.
I would look for:
repo on Github: https://github.com/symfony/icu
open some file: https://github.com/symfony/icu/blob/1.2.x/IcuRegionBundle.php
find namespace
namespace Symfony\Component\Icu;
then search for "Symfony\Component\Icu" in code in PhpStorm or grep
I think the cleanest way is to start with composer and tell it dump all packages that caused your package to install:
For example, I'm trying to figure out why monolog/monolog is installed:
$ composer depends monolog/monolog
symfony/monolog-bundle 2.11.1 requires monolog/monolog (~1.18)
So monolog/monolog was installed because of symfony/monolog-bundle.
As you said you might have unintentionally use a package that's a dependency of another package so you didn't add it to your dependencies.
I'd use grep just as you did to search my source code. Just note that it's better to search for an actual class name, not the package name. Searching for package name would give you composer.json files but that's easier to analyze with composer depends than grep:
$ grep --include=\*.php -rnw './vendor' -e 'use Monolog'
./vendor/monolog/monolog/src/Monolog/ErrorHandler.php:16:use Monolog\Handler\AbstractHandler;
./vendor/monolog/monolog/src/Monolog/Formatter/ChromePHPFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/FluentdFormatter.php:45: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s FluentdUnixFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/GelfMessageFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/HtmlFormatter.php:13:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/NormalizerFormatter.php:34: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s NormalizerFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/WildfireFormatter.php:14:use Monolog\Logger;
This command searches all *.php files and dups also line numbers containing Monolog.
Unfortunately, the these two methods just analyze your code post-mortem. Really the best way to avoid dealing with this is to write unit tests. Then clone your fresh repository, install dependencies with composer install and run tests. This should guarantee that your code is run in isolation from any other unwanted dependencies.
Related
I have a package that I developed to enable my team (and perhaps other interested users) to install and use a particular R package (RQDA) that was archived on CRAN. I have hosted this package on GitHub and am trying to set up GitHub Actions so that I have a CI workflow in place.
Whenever I run R CMD check locally everything is fine, but when I push to GitHub the build fails. This is because, by default, Actions tries to install that same (archived) package. Expectedly, this fails.
So, my question is this: is there a way I can disable the check for a specific package dependency? There are no plans to ever send this package to CRAN, so I am happy to bypass their package policy in this instance.
2 possible ways:
Upload the source for RQDA to a Github repo, or other publicly accessible location, and put a Remotes: line in your DESCRIPTION file
Save the package to cloud storage, eg an S3 bucket or Azure storage container, and download it from there as a separate workflow step prior to checking
This is how I was able to deal with the problem:
The changes made were entirely in the workflow file at ./.github/workflows/. One of the jobs there is for installing R package dependencies for the project:
- name: Install dependencies
run: |
remotes::install_deps(dependencies = TRUE)
remotes::install_cran("rcmdcheck")
shell: Rscript {0}
The first thing I did was to change the dependencies argument to NA so that only packages listed in Depends and Imports are installed. (The RQDA dependency that was giving me trouble is under Suggests).
There was still an error but this time with some guidance that involved going to the job Check and setting the environment variable _R_CHECK_FORCE_SUGGESTS_ to false.
The check now works as expected.
I want to add a feature to FITSIO package and submit a pull request. What is the current workflow for that? Before Pkg 1.0 there were Pkg.checkout and Pkg.submit functions. Are there similar commands that I can run in Pkg v1.1?
Of course, I can manually fork the repository on Github, make changes and submit a pull request. But I wonder if there are convenient shortcuts in Pkg 1.1 for that?
Update
Here is a useful guide that I found.
You can use Pkg.develop (or the develop Pkg REPL command) which will download a full git-clone of the package and put it in $HOME/.julia/dev by default. There you can make your changes and push as usual.
Pkg.develop can also take a path as an argument, so if you have git cloned the repository to some other more convenient folder (as compared to $HOME/.julia/dev) and prefer to work there you can "install" that path by Pkg.develop(PackageSpec(path = "path/to/clone")) and it should be available to load from within Julia.
EDIT:
checkout has been replaced by two new things:
if the intention is just to install the master branch of the package you now do pkg> add Example#master (or Pkg.add(PackageSpec(name="Example", rev="master")));
If the intention is to modify the code you use Pkg.develop.
There does not exist something like Pkg.submit in the new package manager; you have to git push and make a PR yourself.
I am really new to Julia and confused about using an old version of the SISL Vec package.
I am trying to setup ngsim_env and their instructions require you to use an older v0.1.0 of Vec. But, when I followed the instructions to install the Vec package and then checkout the v0.1.0 tag it didn't work.
Here's what I did
$ julia ../build.jl for some package which includes this block
packages = keys(Pkg.installed())
if !in("Vec", packages)
Pkg.clone("https://github.com/tawheeler/Vec.jl.git")
end
Note: This git URL actually goes to the SISL Vec page.
cd ~/.julia/packages/Vec
git fetch tags
git checkout v0.1.0
I did a bunch of other installations with many other packages. At some point I noticed that there is a package ~/.julia/dev/Vec and ~/.julia/packages/Vec. The one in dev has the correct v0.1.0 code and the one in packages has the newer wrong code. When I tried to use other packages that needed the older Vec they were throwing errors and the paths were to files in the packages directory.
I tried Pkg.rm("Vec"). This did something to the project manifest. After nothing worked, every package would throw errors like KeyError: key "Vec" not found and Pkg.add("Vec") nor original Vec installation helped. I even tried removing both the Vec directories from ~/.julia but that didn't help.
I guess a big question is why does Julia put some packages into packages/ and others into dev/ and how to control which one's get used if the same package appears in both places like Vec is.
Would greatly appreciate any assistance, totally confused.
The dev command fetches a full clone of the package to ~/.julia/dev/
via the docs. The only things I have in my dev directory there are the ones I am developing on my own.
I think that triggered when you did a check out manually with git checkout.
Accordingly:
to stop tracking a path and use the registered version again, use free
Try deleting the packages, and whipping mentions of Vec.jl from your manifest:
(v1.0) pkg> rm Vec
(v1.0) pkg> add https://github.com/tawheeler/Vec.jl.git#0.1.0
In general, try using Pkg when possible, cause it does a lot of house keeping magic in the back
(Also, the repl interface with pkg makes everything easier, so hit ] from a blank julia> to get there. And a quick Pkg.status() or ] st will show you what youre tracking and whats in dev and what version you have pinned, etc.)
I am building a debian package using dpkg.
The package has a dependency on libvirt which is not desired.
The rules file does not specify this dependency, but it is added by dpkg, I suppose due to some calls to libvirt-dev at build time.
However my package works fine without libvirt. As such, libvirt is a "Recommended" package but not "Required". How do I override this dependency and make sure it is not present in my final deb file ?
Hard to know without seeing your actual package, but I'd guess that you have a binary or shared library which is linked against libvirt. That would cause dh_shlibdeps to include libvirt in the ${shlibs:Depends} substvar.
If that's your problem, then the right fix depends on what's getting linked to libvirt. It should be straightforward to determine; just run ldd on each binary or shared library object in your package, and grep for "libvirt".
If the thing linked against libvirt is only incidental to the package, and isn't part of the main functionality, then using Recommends: would indeed be the right thing. To make dh_shlibdeps exclude that object from its dependency scanning, give it a -X option. Example target for debian/rules, assuming debhelper7-style packaging:
override_dh_shlibdeps:
dh_shlibdeps -Xname_of_your_object_to_exclude
If the thing(s) linked to libvirt actually are an important part of the package functionality, then the generated libvirt dependency is appropriate. If you still don't want it, you'll need to work out how to avoid linking against libvirt during your build.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)