Feedstock license: BSD-3-Clause
Home: http://htcondor.org/
Package license: Apache-2.0
Summary: HTCondor: High Throughput Computing
Development: https://github.com/htcondor/htcondor
Documentation: https://htcondor.readthedocs.io/
HTCondor is a workload management system for high-throughput and high-performance jobs. Like other full-featured batch systems, HTCondor provides a job queuing mechanism, scheduling policy, priority scheme, resource monitoring, and resource management. Users submit their serial or parallel jobs to HTCondor, HTCondor places them into a queue, chooses when and where to run the jobs based upon a policy, carefully monitors their progress, and ultimately informs the user upon completion.
Home: http://htcondor.org/
Package license: Apache-2.0
Summary: HTCondor's classified advertisement language
Development: https://github.com/htcondor/htcondor
Documentation: https://htcondor.readthedocs.io/
Classified Advertisements (classads) are the lingua franca of HTCondor. They are used for describing jobs, workstations, and other resources. They are exchanged by HTCondor processes to schedule jobs. They are logged to files for statistical and debugging purposes. They are used to enquire about current state of the system.
A classad is a mapping from attribute names to expressions. In the simplest cases, the expressions are simple constants (integer, floating point, or string). A classad is thus a form of property list. Attribute expressions can also be more complicated. There is a protocol for evaluating an attribute expression of a classad vis a vis another ad. For example, the expression "other.size > 3" in one ad evaluates to true if the other ad has an attribute named size and the value of that attribute is (or evaluates to) an integer greater than three. Two classads match if each ad has an attribute requirements that evaluates to true in the context of the other ad. Classad matching is used by the HTCondor central manager to determine the compatibility of jobs and workstations where they may be run.
Home: http://htcondor.org/
Package license: Apache-2.0
Summary: HTCondor utilities library
Development: https://github.com/htcondor/htcondor
Documentation: https://htcondor.readthedocs.io/
Just the HTCondor libcondor_utils shared object library.
Home: http://htcondor.org/
Package license: Apache-2.0
Summary: Python bindings for HTCondor
Development: https://github.com/htcondor/htcondor
Documentation: https://htcondor.readthedocs.io/
The HTCondor Python bindings aim to expose a high-quality, Pythonic interface to the HTCondor client libraries. They utilize the same C++ libraries as HTCondor itself, meaning they have nearly the same behavior as the command line tools.
| Azure |
|
| Name | Downloads | Version | Platforms |
|---|---|---|---|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Installing htcondor from the conda-forge channel can be achieved by adding conda-forge to your channels with:
conda config --add channels conda-forge
conda config --set channel_priority strict
Once the conda-forge channel has been enabled, htcondor, htcondor-classads, htcondor-cli, htcondor-utils, libcondor_utils, python-htcondor can be installed with conda:
conda install htcondor htcondor-classads htcondor-cli htcondor-utils libcondor_utils python-htcondor
or with mamba:
mamba install htcondor htcondor-classads htcondor-cli htcondor-utils libcondor_utils python-htcondor
It is possible to list all of the versions of htcondor available on your platform with conda:
conda search htcondor --channel conda-forge
or with mamba:
mamba search htcondor --channel conda-forge
Alternatively, mamba repoquery may provide more information:
# Search all versions available on your platform:
mamba repoquery search htcondor --channel conda-forge
# List packages depending on `htcondor`:
mamba repoquery whoneeds htcondor --channel conda-forge
# List dependencies of `htcondor`:
mamba repoquery depends htcondor --channel conda-forge
conda-forge is a community-led conda channel of installable packages. In order to provide high-quality builds, the process has been automated into the conda-forge GitHub organization. The conda-forge organization contains one repository for each of the installable packages. Such a repository is known as a feedstock.
A feedstock is made up of a conda recipe (the instructions on what and how to build the package) and the necessary configurations for automatic building using freely available continuous integration services. Thanks to the awesome service provided by Azure, GitHub, CircleCI, AppVeyor, Drone, and TravisCI it is possible to build and upload installable packages to the conda-forge anaconda.org channel for Linux, Windows and OSX respectively.
To manage the continuous integration and simplify feedstock maintenance
conda-smithy has been developed.
Using the conda-forge.yml within this repository, it is possible to re-render all of
this feedstock's supporting files (e.g. the CI configuration files) with conda smithy rerender.
For more information please check the conda-forge documentation.
feedstock - the conda recipe (raw material), supporting scripts and CI configuration.
conda-smithy - the tool which helps orchestrate the feedstock.
Its primary use is in the construction of the CI .yml files
and simplify the management of many feedstocks.
conda-forge - the place where the feedstock and smithy live and work to produce the finished article (built conda distributions)
If you would like to improve the htcondor recipe or build a new
package version, please fork this repository and submit a PR. Upon submission,
your changes will be run on the appropriate platforms to give the reviewer an
opportunity to confirm that the changes result in a successful build. Once
merged, the recipe will be re-built and uploaded automatically to the
conda-forge channel, whereupon the built conda packages will be available for
everybody to install and use from the conda-forge channel.
Note that all branches in the conda-forge/htcondor-feedstock are
immediately built and any created packages are uploaded, so PRs should be based
on branches in forks and branches in the main repository should only be used to
build distinct package versions.
In order to produce a uniquely identifiable distribution:
- If the version of a package is not being increased, please add or increase
the
build/number. - If the version of a package is being increased, please remember to return
the
build/numberback to 0.