When I using conda search anaconda I found a few custom version packages, shown as follow:
Fetching package metadata: ....
anaconda 1.6.0 np17py33_0 defaults
... ... ...
4.0.0 np110py35_0 defaults
4.0.0 np110py34_0 defaults
4.0.0 np110py27_0 defaults
custom py35_0 defaults
custom py34_0 defaults
custom py27_0 defaults
Note that these three custom version pkgs are shown at the end of conda search anaconda results, so they are considered the newest version by conda, which also affects conda install anaconda results (so I have to using conda install anaconda=4.0.0).
Then conda info anaconda=custom gives following results:
Fetching package metadata: ....
anaconda custom py35_0
----------------------
file name : anaconda-custom-py35_0.tar.bz2
name : anaconda
version : custom
build number: 0
build string: py35_0
channel : defaults
size : 3 KB
date : 2016-03-14
license : BSD
md5 : 47c237b38bfc175cb73aed8b8b33ade7
space : python
installed environments:
dependencies:
python 3.5*
anaconda custom py34_0
----------------------
file name : anaconda-custom-py34_0.tar.bz2
name : anaconda
version : custom
build number: 0
build string: py34_0
channel : defaults
size : 3 KB
date : 2016-03-14
license : BSD
md5 : 767a59923372d998b8c83fb16ac035a1
space : python
installed environments:
dependencies:
python 3.4*
anaconda custom py27_0
----------------------
file name : anaconda-custom-py27_0.tar.bz2
name : anaconda
version : custom
build number: 0
build string: py27_0
channel : defaults
size : 3 KB
date : 2016-03-14
license : BSD
md5 : 8288aef529d5a46d07bd84b4fcf4308a
space : python
installed environments:
dependencies:
python 2.7*
BUT I don't know/remeber HOW and WHY these three packages appear in this computer, can anyone explain:
How these custom version pkgs are created in the first place?
How/Why these custom version pkgs are shown in the conda search results?
How to remove these custom version pkgs?
The one custom version of any package that exists (right now, in the official repos) is for the anaconda package.
Here's there reason... The anaconda conda packages are metapackages, meaning they are packages of packages--or packages that have no real source code and only bring in a bunch of dependencies. Each anaconda package has every sub-package pinned to an explicit and specific version of that sub-package. That's because Continuum does extensive testing on the interoperability of that set of packages (and those specific versions).
Now, after you've installed anaconda, either through the Anaconda Installer or installing Miniconda and then conda install anaconda, you have a set of packages with all of these tested guarantees. There's no reason you have to stick to this locked set of packages--you can install anything and any version you want. You no longer have a version-identifiable Anaconda Distribution though. You've customized it. Thus, when you run conda list and the version of the anaconda package shows custom, you know you've diverged from the set of packages in the Anaconda Distribution that are robustly tested for interoperability.
Your conda search anaconda query just reflects an artifact of how this is implemented. You'll notice in that query that custom packages are listed first, meaning they have the lowest sort order when comparing versions. Thus, if you run conda update anaconda after you've diverged from the specifically-pinned anaconda packages, you'll be back to a numbered version of the Anaconda Distribution.
This is really a partial answer. I'm not positive why exactly this version exists.
(1) In terms of the specific version value of custom it seems this is allowed from here:
version: string
The package version, which may not contain -. Conda acknowledges PEP 440.
So this anaconda package would be created in the same way as any of the other versions. I would assume using conda build.
(2) They are shown in the search results because they exist in the anaconda cloud. It seems this is an officially released version of anaconda.
As for why it exists, if you download one of the actual package files (for example linux-64-anaconda-custom-py35_0.tar.bz2), expand it, and read the info/index.json file it looks like this package will simply install python and the other bare bones needs. Compare this to anaconda version 4.0.0, or one of the others, and you will see a ton of packages. I assume this package exists so that if someone installs the custom version they will just get the bare bones packages and then they go through conda install-ing any others they want.
For example, look at the packages when you do conda create -n anc-test anaconda=4.0.0 vs. conda create -n anc-test anaconda=custom.
EDIT: Just saw that that is also in your conda info so you are probably already aware of the difference in dependencies.
(3) I don't think you can remove these custom packages from your search call as they are legitimate packages in the anaconda cloud. You might be able to exclude them from the conda search via regex. It doesn't look like from your output that they have been installed -- at least not in the current environment.
Related
I am using Spyder version 5 the standalone version with Miniconda.
I was hoping someone could shed some light on the following questions:-
I know how to update all the packages within a given environment, however does anyone know what the command is to update a specific package within a given environment and how to delete a specific package within a given environment?
Does anyone know what the command is to upgrade Python from say 2.7 to 2.8 using Spyder standalone within mini conda.
When I remove an environment I get the following message in mini conda:-
"Remove all packages in environment C:\ProgramData\Miniconda3\envs\minicdm:" - Whats all this about???
And finally I am trying to create a list of common commands for newbies like myself and I was wondering if anyone could add anything to the list I currently have:-
4.1 conda env list - List all environments and places an asterisk to which environment is active.
4.2 conda deactivate - Deactivates active environment, you may or may not need to be in the folder to deactivate it
4.3 conda env remove -n - Removes the environment, must be deactivated before it can be removed.
4.4 conda update -n --all - Updates all the packages within a given environment.
4.5 conda create -n -y - Creates a conda environment
4.6 conda activate - Activates a conda environment
4.7 conda install spyder-kernels scikit-learn -y - Installs a package in the activate environment
Thank you.
Do not rely on third-party information. Read the the docs:
https://docs.conda.io/projects/conda/en/latest/user-guide/index.html
I attempted to upgrade my tcms-api library from 5.0 to 5.3 using:
pip install tcms-api --upgrade
on a Windows 10 machine, I saw a lot of errors when trying to install the dependent package of kerberos. Even though this is old, I saw a similar set of errors. The package installation failed since the kerberos package isn't supported on Windows and I was left at tcms-api 5.0.
Please file a bug against https://github.com/kiwitcms/tcms-api.
We can do a quick fix by providing 2 package names:
tcms-api and tcms-api[kerberos]
The first one will not install the kerberos package.
The proposed workaround makes sense but changing the underlying kerberos implementation needs careful testing which isn't a quick job.
OTOH https://github.com/kiwitcms/python-social-auth-kerberos uses gssapi which seems to be the latest and most actively maintained implementation of Kerberos for Python. There is an open issue to migrate to that in tcms-api so you can contribute if you want.
As a workaround, I was able to do the following (caveat: I haven't extensively tested my installation yet):
Clone the tcms-api repo from GitHub
Edit setup.py to change the install_requires line to use 'kerberos-sspi' rather than 'kerberos'
Install the following pip packages: Setuptools, Wheel, Twine
CD to repo folder and run: python setup.py bdist_wheel
That creates a package under the dist folder
Run pip install dist\tcms_api-5.3-py3-none-any.whl
Celebrate successful package install
The steps were modified from this page.
Update:
I confirmed the things I need the API to do work with my custom package (create and update test runs). However, I'm in a situation where I don't need to specifically harden my Kiwi instance using kerberos authentication.
I tried to import the biopython package in Spyder and got the error message:
ModuleNotFoundError: No module named 'biopython'
although biopython is installed.
I also checked the PYTHONPATH: there is a path set into the directory where the packages are stored.
Can somebody help? Did I miss something? Thanks for your help!
If you're using Anaconda, it's best to install all the packages you want from Anaconda if possible. You can check if a package is available with (e.g.):
conda search biopython
When I try that command it shows that biopython is available, so assuming you have access to the standard conda channels you should be able to get it this way.
Assuming you haven't already created a conda environment to work with, start by creating a new one with the packages you want to use:
conda create -n myenvname spyder biopython
where myenvname is the name you want to give the environment - call it whatever you like. If you want to use other packages as well, add their names to the end of this command. Then once the env is completed, activate it:
activate myenvname
or if this doesn't work, on Mac or Linux:
source activate myenvname
and start Spyder in this environment:
spyder
Each time you want to use this environment in future you will need to activate it first. You may also be able to do some of these tasks through the Anaconda Navigator or via Start menu shortcuts but the command line version will always work.
If there's a package you want that isn't available from conda but is available via pip, just use the pip command after creating and activating the environment.
If you are using Anaconda, a solution could be
conda install -c main biopython
following https://anaconda.org/main/biopython.
The official repository page helped me when I got your error message because numpy was not in place.
With a .NET Framework library you could specify a version with a wildcard and NUGET pack command would append the build date and version automatically when running a NUGET Build Task in VSTS.
[assembly: AssemblyVersion("1.0.*")]
NUGET PACK would generate a NUPKG file with a version like 1.0.6604.1234 appending the date number and a build ID.
NET Standard issues
In .NET Core and .NET standard the new .csproj format does not support this wildcard format.
We can't package with Nuget.exe (reason: this issue) but we can use dotnet pack except I need to auto-increment the build numbers. The dotnet Build Task in VSTS allows me to wholly replace the version number, but I want to retain the version in the csproj file, and just append a build number (as I used to).
I found that using <VersionPrefix>x.y</VersionPrefix> in the csproj file would work with nuget pack and I could then add the additional parameter VersionSuffix=$(Build.BuildNumber) to the pack task.
All looked good until the first dev updated the project version in the project properties dialog. Visual Studio ignored the VersionPrefix and set the <Version> tag - and the build number fix is ignored because a Version tag exists.
Is there a way to read the Version from the csproj? If so I could set the build property to Version=$(ProjectVersion).$(Build.BuildNumber) ?
Or are there alternative ways to handle auto-incrementing the build version when packaging?
First you can select Use an environment variable for Automatic package versioning, use your defined variable such as temp ($(build.buildNumber)) as Environment variable.
More details take a look at this link: Dotnet pack automatic package versioning build number clarification
Another way is using the "arguments" field in the dotnet CLI task, you can pass additional arguments to the dotnet cli.
Using --version-suffix $(Build.BuildNumber) will pass the build
number as version suffix. Make sure you don't have a <version>
element set in your csproj, but rather a <versionprefix> element.
The built version will look like versionprefix-versionsuffix, so for
example, if you have <versionprefix>1.2.3</versionprefix> and build
number 201805002, the built version will be 1.2.3-201805002. In this case do not select the automatic package versioning.
Thanks to #patricklu-msft for his suggestions.
There is it appears no built-in way to emulate the wildcard behaviour we previously had NUGET pack with dotnet pack, nor was there way to get the <Version> tag out of the project file.
So I've created a new VSTS Build task that does this: VersionTaskReader in the MarketPlace.
This extension can be pointed to a .csproj or .vbproj and will set an environment variable VERSION, and VERSION_BUILD which has the BUILDID appended. You can optionally add a prefix to make each instance different if needed.
For example, if your project contains <Version>1.1</Version> then the VERSION_BUILD would be something like 1.1.8680
Then the dotnet pack task can use the environment variable VERSION_BUILD in the versioning options screen, so that the build number automatically increments.
The Python 3.5 "embedded distribution" is a ZIP file containing
pyexpat.pyd
python.exe
python3.dll
python35.dll
python35.zip
pythonw.exe
pyvenv.cfg
select.pyd
sqlite3.dll
unicodedata.pyd
vcruntime140.dll
winsound.pyd
_bz2.pyd
_ctypes.pyd
_decimal.pyd
_elementtree.pyd
_hashlib.pyd
_lzma.pyd
_msi.pyd
_multiprocessing.pyd
_overlapped.pyd
_socket.pyd
_sqlite3.pyd
_ssl.pyd
I need to install pywin32
https://pypi.python.org/pypi/pywin32
https://sourceforge.net/projects/pywin32/files/pywin32/
http://docs.activestate.com/activepython/2.7/pywin32/PyWin32.HTML
The installer requires the specific python version to be installed on the system. Target paths cannot be provided manually.
The installer can be unzipped but I am not familiar with the packaging system, so I cannot do a manual install.
I found https://bootstrap.pypa.io/get-pip.py which manages to get Scripts/pip.exe and creates Lib/site-packages.
But:
tools\python
>pip install pywin32
Could not find a version that satisfies the requirement pywin32 (from versions: )
No matching distribution found for pywin32
Solution moved to answer.
It would be interesting to know how manually install the package from the the current installer (or how to get the installer to use a specified path).
There is a (slightly older) release of pywin32 as Python wheel at https://pypi.python.org/pypi/pypiwin32
> pip.exe install pypiwin32
Collecting pypiwin32
Downloading pypiwin32-219-cp35-none-win32.whl (7.9MB)
100% |################################| 7.9MB 114kB/s
Installing collected packages: pypiwin32
Successfully installed pypiwin32-219
Test:
import win32clipboard
win32clipboard.OpenClipboard()
win32clipboard.EmptyClipboard()
win32clipboard.SetClipboardText( 'Hello World!', win32clipboard.CF_TEXT )
win32clipboard.CloseClipboard()
> python test.py
Paste: Hello World!