How to view all modules instead of help('modules')? - enthought

Given that help('modules') has been disabled in enthought because of this python bug, how can one get a list of all the modules they have? I know that enpkg --list shows all the packages installed with Enthought, but is there a way to view ALL packages or modules?

In ipython terminal, if you type "import", then type a space and press the tab key, you will see ipython's best guess at all the modules that you could import. This list might not be complete, because python lets developers customize the behavior of the import command. The list will also include internal modules which you should not actually import. If you precede the tab by other characters, these will filter the list to modules beginning with those characters.
Note that most complex packages contain many modules. Looking at the subdirectories in your python site-packages directory, and at the contents of the file site-packages/easy-install.pth is another way to see typically installed 3rd party installed packages.

Related

Call a chocolatey package in powershell based on its package name

I recently set up a new machine and installed/enabled chocolatey. As far as I can remember I was able to call a package via powershell based on the package name. For instance, if I wanted to install mongodb, I used to type choco install mongodb - and was able to call the mongo client by simply typing mongo in the powershell console. Is there a way to see if something is bound to a specific shim ? or is there an option to enable it?
I don't think there is a way to match packages with shims, but you can check the executable a shim points to, along with general information about it and what would happen if you run the shim:
shimname.exe --shimgen-noop
I tried crafting a command to check all the shims in the $env:ChocolateyInstall\bin directory, but there's no guarantee that executables there are going to be a shim. I tried filtering out the known Chocolatey executables as well, but some packages (like putty) drop their real executables right in the bin folder, and won't respond to the shim parameters like you'd expect.
Looking at the Install-BinFile cmdlet, it doesn't look like Chocolatey provides a way to track shims at all as it doesn't even do this itself. I think it uses the same logic to track automatically generated shims at package uninstall time, but any shims explicitly created with Install-BinFile also need to have Uninstall-BinFile called in the associated chocolateyUninstall.ps1 script or the shim won't be removed at package uninstall time.
Short of crawling the $env:ChocolateyInstall\lib\packageName directory for potential automatic shim names, or the chocolateyInstall.ps1/chocolateyUninstall.ps1 scripts for explicit shims, you're not going to be able to match a shim to a package.

Emacs packages, installing globally versus locally with elpa

I run linux and use different user names to segment different activities.
Using elpa, there are some packages that I would like to install so that they get loaded no matter who the user, there are packages that I would like to be loaded for only one user.
Org-mode for example is something I would want to be loaded by every user.
C++ related packages I might want for user client1, but not ruby packages.
I might want ruby related packages for user client2, but not C++ packages.
There might be a new package for C++ programming that I do not want to include in serious work but want to play with using user experimental.
It used to be that global stuff you put in site lisp and local stuff you put someplace in ~, but that doesn't seem to work with elpa.
package.el looks for installed packages along the package-directory-list path (additionally to package-user-dir which is where packages get installed).
So I'd recommend you arrange to have a "global" user. And then change all other users to include
(require 'package)
(push "/home/globaluser/.emacs.d/elpa" package-directory-list)
in their ~/.emacs. This way, any package that you want to install for all users should be installed by globaluser.
BTW, another way to attack the vector is to distinguish "installed" and "enabled". I.e. always install your packages globally, and then have each user tweak its package-load-list in order to disable specific packages.
Finally any package whose mere installation&enabling (where "enabling" means to load the package's own -autoloads.el) ends up interfering with normal work is a bug (in my book), so yet another solution is to just install and enable all packages globally. And if the C++-using-user gets annoyed by some ruby-related packages, then file a bug report to the maintainer of the ruby-related package.

Does use of 'virtualenv' leave my "real" Python installation alone?

I've had many questions about Python for which a suggested answer is often "use virtualenv", but I have a (lovingly maintained and perfectly functioning) Python installation that I'm loath to disturb.
I want to be absolutely sure, so I'll ask twice: Does use of virtualenv in any way disturb my "real" Python installation? Using virtualenv does not in any way modify the files or paths in my "real" installation, right?
Virtualenv creates separated Python environment. Python interpreter is linked from one of system-installed that you choose creating virtualenv( --python commandline switch) and, optionally, wheater use or not system site-packages (--system-site-packages).
All packages that you install using virtualenv remains only on virtualenv directory site-packages folder and do not mess system packages.

cmake which package name to pass to find_package

I am trying to link against the libconfig++ library using cmake. I installed the library
using apt-get so I am assuming it will have a .cmake file so I can use find_package. Problem is I don't know what package name to use. I tried libconfig, config, config++ as the package name to no avail.
As a general question, how does one find out which package is associated with a library.
I know that find_package looks into CMAKE_MODULE_PATH to see if there is a .cmake script. How to I find out what is the value of CMAKE_MODULE_PATH on my system. It's not an environment variable. I am running ubuntu 12.04.
Any help is appreciated.
To use find_package you need to have corresponding Find or Config cmake file. But library may not to provide it, seems with your library is such a case. You can use find_library for finding libraries and find_path to find include directories. With these commands you can even write FindXXX.cmake yourself.
CMAKE_MODULE_PATH is not an environment variable, it is CMake's one. This variable is intended for you to set, if you have additional directories with modules, by default it's empty. This is used in the "Module" mode. In this mode CMake searches FindXXX.cmake in the CMAKE_MODULE_PATH (your modules) or in modules shipped with CMake and if it's found, it then used to find library and it's headers.
If that module wasn't found, it then switches into "Config" mode. On Unix it searches for ConfigXXX.cmake in the following directories:
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/
This files is shipped with the library, so there is no need to find anything, they contain all information, where library and includes located, etc.
About naming scheme, there is no standard one. You can look at Standard CMake modules. Modules found in internet for your library named FindLibConfig.cmake
For your case, library ships without corresponding cmake file, so you should write it your self (or find already written) and add directory with that file to CMAKE_MODULE_PATH.
I suggest you to read how find_package command works and how to write FindXXX.cmake files.

dpan does not find Perl module in package root

We use MyCPAN::App::DPAN (Version 1.28) just like in Question: How can I manage Perl module dependencies?
This works quite well in general. But we ran into troubles with some specific packages:
As expample DBD::Oracle does not have their main *.pm file in DBD-Oracle-1.27/lib/DBD/Oracle/Oracle.pm but in DBD-Oracle-1.27/Oracle.pm.
It seems that dpan does not find this *.pm file, since it is not listed in modules/02packages.details.txt.gz. Whereas DBD::Oracle::Object (other Perl-Module of this distribution, but located DBD-Oracle-1.27/lib/DBD/Oracle/) is listed there.
In dpan.conf we only have set the recommended values:
dpan_dir /some/dir
indexer_id Me
pause_full_name The Admin Team
pause_id TAT
system_id my system id
Other Packages with the same problem:
Apache::DB
Packages that work:
Crypt::Blowfish (no extra modules)
Math::Round (no extra modules)
XML::Twig (no "lib" dir, but extra modules)
Does someone have any tips/hints?
DPAN works by indexing the distributions and storing the results in a file in the indexer_reports directory. As a workaround until I can investigate your problem, you can just edit the report it created for the problem distributions. As long as you haven't set fresh_start in your configuration, it will use the cached report which you have edited to add the missing module.