[DEPRECATED] YUM package manager

Related tags

yum
Overview

This project is deprecated. Please use DNF, the successor of YUM.

YUM

Yum is an automatic updater and installer for rpm-based systems.

Included programs:

/usr/bin/yum		Main program

Usage

Yum is run with one of the following options:

  • update [package list]

    If run without any packages, Yum will automatically upgrade every currently installed package. If one or more packages are specified, Yum will only update the packages listed.

  • install <package list>

    Yum will install the latest version of the specified package (don't specify version information).

  • remove <package list>

    Yum will remove the specified packages from the system.

  • list [package list]

    List available packages.

See the man page for more information (man yum). Also see:

3.2.X Branch - yum-3_2_X
      Starting commit is roughly: a3c91d7f6a15f31a42d020127b2da2877dfc137d
         E.g. git diff a3c91d7f6a15f31a42d020127b2da2877dfc137d

Building

You can build an RPM package by running:

$ make rpm

Note: Make sure you have mock and lynx installed.

Development

You can run Yum from the current checkout in a container as follows (make sure you have the podman package installed):

$ make shell

This will first build a CentOS 7 image (if not built already) and then run a container with a shell where you can directly execute Yum:

[[email protected] /] yum

When you edit the code on your host, the changes you make will be immediately reflected inside the container since the checkout is bind-mounted.

Warning: There's a (probably) bug in podman at the moment which makes it not see symlinks in a freshly created container, which, in turn, makes Yum not see the /etc/yum.conf symlink when it runs for the first time. The workaround is to touch /etc/yum.conf or simply re-run Yum.

Note: When you exit the container, it is not deleted but just stopped. To re-attach to it, use (replace the ID appropriately):

$ podman start bf03d3a43cbf
$ podman attach bf03d3a43cbf
Issues
  • Don't crash on invalid repoid from yumdb

    Don't crash on invalid repoid from yumdb

    Ensure the ui_from_repo property always returns ascii-only strings.

    Previously, if the yumdb had been tampered with and a repoid was corrupted for some reason so that it contained non-ascii chars, we could end up reading it and then crash on an implicit conversion to unicode, e.g. in output.fmtColumns().

    We could also explicitly convert the data passed to fmtColumns() but that may not fix this completely as we couldn't guarantee that, with the same corrupted repoid, such an implicit conversion wouldn't happen elsewhere. Likewise, doing the conversion in ui_from_repo and returning a unicode string may cause an implicit conversion elsewhere.

    opened by dmnks 15
  • install command will return error code 1 if package is already installed

    install command will return error code 1 if package is already installed

    A lot of installation scripts rely on exit code of commands, and it will exit if any of subcommands has non-zero exit code. Yum may return error code (1) in case package is already installed (imho it is not an error)

    Example:

    Step 1 (first install):

    yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; echo $?
    ...
    Installed:
      epel-release.noarch 0:7-11                                                                                                                                                                                                               
    
    Complete!
    0
    

    Step 2 (install the same package):

    yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; echo $?
    ...
    /var/tmp/yum-root-dE0FBq/epel-release-latest-7.noarch.rpm: does not update installed package.
    Error: Nothing to do
    1
    

    Step3 (wrong path):

    yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch__BUG__.rpm; echo $?
    Loaded plugins: fastestmirror
    Cannot open: https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch__BUG__.rpm. Skipping.
    Error: Nothing to do
    1
    

    Suggestion:

    A) return 0 exit code (no_error) in _already_installed_case or B) use different error exit code

    Alt solutions I found:

    1. use localinstall:

    will return 0, but it also will return 0 in wrong cases,
    like:
    
    yum -y localinstall https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch_BUG.rpm || echo $?
    Loaded plugins: fastestmirror, versionlock
    Cannot open: https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch_BUG.rpm. Skipping.
    Nothing to do
    0
    

    2. use reinstall:

    works fine, but it will REINSTALL it every time (trade off: at least time)
    

    Reference:

    https://github.com/rpm-software-management/yum/blob/master/yum/init.py#L5654

    opened by 0x7162 13
  • depsolve: penalize conflicting provider. BZ 1480065

    depsolve: penalize conflicting provider. BZ 1480065

    When there are multiple providers available for a requirement, yum would happily pick the one that the requiring package also has a "Conflicts:" on (via another virtual provide), failing to resolve the transaction.

    Example:

    • foo requires bar and conflicts my-bar
    • bax provides bar
    • bay provides bar, my-bar

    Yum might decide to pick bay, only to fail due to the conflict with foo later in the process.

    This commit fixes that by penalizing such a provider so that it's unlikely for it to be selected during depsolving.

    opened by dmnks 9
  • Yum history always shows user as System <unset> in AIX

    Yum history always shows user as System in AIX

    yum history

    ID | Command line | Date and time | Action(s) | Altered

    272 | erase -y bison | 2017-06-09 03:24 | Erase | 1 EE 271 | install -y bison | 2017-06-09 03:24 | Install | 1 EE 270 | erase -y git | 2017-06-09 02:22 | Erase | 1 269 | install -y git | 2017-06-09 02:22 | Install | 1 268 | erase -y git | 2017-06-08 21:55 | Erase | 1 267 | install make | 2017-06-07 09:54 | Install | 1 EE 266 | install subversion | 2017-06-07 09:49 | Install | 1 265 | install httpd | 2017-06-07 09:48 | Install | 2 EE 264 | install tla | 2017-06-07 09:44 | Install | 3 EE 263 | install bash curl expat | 2017-06-07 09:44 | Update | 2 EE 262 | install coreutils curl-d | 2017-06-07 09:43 | Install | 1 261 | erase grep-3.0-1.ppc | 2017-06-07 06:41 | Erase | 1 260 | erase -y pcre | 2017-06-07 03:00 | Erase | 1 259 | install -y pcre | 2017-06-07 03:00 | Install | 1 258 | install grep | 2017-06-07 02:09 | Install | 1 257 | erase -y pcre | 2017-06-07 01:38 | Erase | 3 EE 256 | erase -y vim | 2017-06-07 01:10 | Erase | 1 255 | install -y vim | 2017-06-07 01:09 | I, U | 2 254 | erase -y vim | 2017-06-07 00:37 | Erase | 1 253 | install -y vim | 2017-06-07 00:37 | Install | 1 history list

    (0) root @ aixoss-automation-2: 6.1.0.0: /opt/freeware/etc/yum/repos.d

    yum history info 263

    Transaction ID : 263 Begin time : Wed Jun 7 09:44:04 2017 Begin rpmdb : 107:4862ad7227bc760f3d3f5f0c4cf3c4410c7ff593 End time : 09:44:15 2017 (11 seconds) End rpmdb : 107:a3665a21e5b27567f29a034aa57fe2870fed5222 User : System Return-Code : Success Command Line : install bash curl expat gettext less perl python rsync zlib Transaction performed with: Installed yum-3.4.3-4.noarch installed Packages Altered: Updated bash-4.3.30-1.ppc @?AIX_Toolbox_local Update 4.4-1.ppc @AIX_Toolbox_local Updated less-481-1.ppc @?AIX_Toolbox_local Update 487-1.ppc @AIX_Toolbox_local

    opened by ayappanec 8
  • skipbroken: don't remove old pkg on dep problems

    skipbroken: don't remove old pkg on dep problems

    This fixes a typo in f8c15289427c24130a7cdf5bf2f9eb524fc3fa19 that caused the patch to be ineffective. The problem was that we were storing a txmbr in TransactionMember.depends_on later in the function, while we expect package objects there.

    opened by dmnks 7
  • Print a disk usage summary on

    Print a disk usage summary on "yum clean all". BZ 1481220

    Replace the confusing "rm -rf" hint with actual info on how much data is still left behind in the cache.

    This commit also removes the "Cleaning up everything" message since "everything" was often understood by users as "everything ever cached".

    opened by dmnks 7
  • yum-cron: reintroduce days_of_week parameter

    yum-cron: reintroduce days_of_week parameter

    In previous versions of yum_cron we had available to us the days_of_week parameter. This patch reintroduces that behavior, and adds the default days_of_week setting in the sample configuration files.

    opened by whereismyjetpack 6
  • Fix #95

    Fix #95

    This commit should fix issue #95

    opened by dnagl 5
  • yum-cron emits messages even with debuglevel=-4

    yum-cron emits messages even with debuglevel=-4

    I have enabled yum-cron to make some servers self-maintain as much as possible. But in case they don't, it's not the end of the world (regular manually initiated yum updates will take care of things, in case automation has failed).

    Therefore, I don't want to get error mails from yum like this:

    /etc/cron.hourly/0yum-hourly.cron:
    
    Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was
    14: HTTPS Error 503 - Service Unavailable
    

    I only ever want to hear from yum-cron, if it runs into rpm database corruption, or something of that severity.

    Consequently, I've adjusted /etc/yum/yum-cron-hourly.conf and /etc/yum/yum-cron.conf, so that emit_via = debuglevel = -4

    Still, I get error mails like the above quoted once in a while. I'm seeing this on some CentOS 7.2 servers. I have seen something similar on RHEL servers (but on the RHEL servers, I've simply stopped using yum-cron, in order to cut down on mail-noise).

    I believe it's due to the _getMetalink method in yum/yumRepo.py. It prints an error message without considering debuglevel. I don't know it is best fixed, though.

    A way to reproduce the error: Adjuste /etc/yum/yum-cron-hourly.conf, asking yum-cron to download updates, but keep silient (see above) with a temporary iptables rule which drops packets to port 443/tcp. Run /etc/cron.hourly/0yum-hourly.cron (For the sake of testing, it's also nice to have random_sleep=0, so that calling /etc/cron.hourly/0yum-hourly.cron doesn't start by sleeping for a while.)

    opened by troelsarvin 4
  • ImportError: cannot import name exception2msg

    ImportError: cannot import name exception2msg

    hi, I encountered this error while installing yum. Could you help me ?

    Traceback (most recent call last): File "/usr/bin/yum", line 28, in import yummain File "/usr/share/yum-cli/yummain.py", line 32, in from yum.i18n import utf8_width, exception2msg ImportError: cannot import name exception2msg

    opened by bultiful 0
  • yum gets deadlocked/hung up (indefinitely) waiting for urlgrabber-ext-down

    yum gets deadlocked/hung up (indefinitely) waiting for urlgrabber-ext-down

    While I can appreciate that YUM is now deprecated, it's still the main package manager for EL7, which is where I am running into an issue with it just hanging indefinitely, until it is killed.

    The process tree looks like this:

     8702 ?        S      0:05  |       \_ /usr/bin/python /usr/bin/yum -y --disablerepo=* --enablerepo=repo.dc.hpdd.intel.com_repository_*,build.hpdd.intel.com_job_daos-stack* install --exclude openmpi daos-1.1.2.1-1.5456.g02ce0510.el7.x86_64 daos-client-1.1.2.1-1.5456.g02ce0510.el7.x86_64 daos-tests-1.1.2.1-1.5456.g02ce0510.el7.x86_64 daos-server-1.1.2.1-1.5456.g02ce0510.el7.x86_64 openmpi3 hwloc ndctl fio patchutils ior-hpc-daos-0 romio-tests-cart-4-daos-0 testmpio-cart-4-daos-0 mpi4py-tests-cart-4-daos-0 hdf5-mpich2-tests-daos-0 hdf5-openmpi3-tests-daos-0 hdf5-vol-daos-mpich2-tests-daos-0 hdf5-vol-daos-openmpi3-tests-daos-0 MACSio-mpich2-daos-0 MACSio-openmpi3-daos-0 mpifileutils-mpich-daos-0
     8705 ?        S      0:00  |           \_ /usr/bin/python /usr/libexec/urlgrabber-ext-down
     8711 ?        S      0:00  |           \_ /usr/bin/python /usr/libexec/urlgrabber-ext-down
     8712 ?        S      0:00  |           \_ /usr/bin/python /usr/libexec/urlgrabber-ext-down
    

    The status of the processes are:

    # /tmp/strace -f -p 8702
    /tmp/strace: Process 8702 attached
    wait4(8711, ^C/tmp/strace: Process 8702 detached
     <detached ...>
    # /tmp/strace -f -p 8705
    /tmp/strace: Process 8705 attached
    read(0, ^C/tmp/strace: Process 8705 detached
     <detached ...>
    # /tmp/strace -f -p 8711
    /tmp/strace: Process 8711 attached
    futex(0x1444c90, FUTEX_WAIT_PRIVATE, 2, NULL^C/tmp/strace: Process 8711 detached
     <detached ...>
    # /tmp/strace -f -p 8712
    /tmp/strace: Process 8712 attached
    futex(0x2174c90, FUTEX_WAIT_PRIVATE, 2, NULL^C/tmp/strace: Process 8712 detached
     <detached ...>
    

    which to me looks like 8702, 8711 and 8705 are deadlocked all waiting/blocked on each other.

    opened by brianjmurrell 5
  • Sender email address does not appear to be treated the same way for the envelope level as it is for email headers

    Sender email address does not appear to be treated the same way for the envelope level as it is for email headers

    Let's assume that the system is named cheetah.

    It appears that the logic used to replace [email protected] with [email protected] works as intended for the email headers, but does not apply to the address used as the sender address (the envelope) when sending the email message.

    This code:

    https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/yum-cron/yum-cron.py#L244-L247

    appears to replace [email protected] with [email protected] and store the result in domain. The domain variable is then used here:

    https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/yum-cron/yum-cron.py#L247 to form msg['From'].

    We can see here:

    https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/yum-cron/yum-cron.py#L254

    that the msg type is converted to a string to form the complete email headers/body (I may be butchering this description) as the last argument to the s.sendmail() call.

    The first part of the s.sendmail() call appears to use the email_from value as-is without any conversion, so if the configuration has [email protected], then this is used as-is for the first argument in the s.sendmail() function call.

    Is this intentional?

    Looking here:

    https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/etc/yum-cron.conf#L33-L36

    and here:

    https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/etc/yum-cron.conf#L50-L59

    I don't see this behavior documented as intentional.

    Is this a documentation problem or is the s.sendmail() function call intended to be called this way:

                s.sendmail(msg['From'], self.opts.email_to, msg.as_string())
    
    opened by atc0005 0
  • Avoiding compatibility errors with python 3

    Avoiding compatibility errors with python 3

    I know that yum will be deprecated, so no python 3 support is expected. The best thing to do would be to change all scripts from #!/usr/bin/python to #!/usr/bin/python2.7 This would give people freedom to choose default version of python without errors

    opened by LorenzoSacchi 3
  • yum-builddep not abiding by BuildRequires: package range

    yum-builddep not abiding by BuildRequires: package range

    A packaging fubar was made and a package was made with a pre-release tag in it without using the ~ indicator. So now my repo has foo-2.0.0a1 in it. That fubar was fixed and foo-2.0.0~a1 is now also in the repository.

    But now I want to update another package to use the proper foo package. So I've added to it's spec BuildRequires: foo < 2.0.0a1 and that works and selects foo-2.0.0~a1 with yum-builddep.

    $ sudo yum-builddep bar.spec 
    ...
    Getting requirements for bar.spec
     --> foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Running transaction check
    ---> Package foo-devel.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
    --> Processing Dependency: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7 for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libfoo.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libfoo_hl.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libfoo_util.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libna.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Running transaction check
    ---> Package foo.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    =================================================================================================================================================
     Package                           Arch                       Version                                          Repository                   Size
    =================================================================================================================================================
    Installing:
     foo-devel                         x86_64                     2.0.0~a1-1.git.4871023.el7                       my_repo                      58 k
    Installing for dependencies:
     foo                               x86_64                     2.0.0~a1-1.git.4871023.el7                       my_repo                     103 k
    
    Transaction Summary
    =================================================================================================================================================
    Install  1 Package (+1 Dependent package)
    
    Total download size: 161 k
    Installed size: 597 k
    Is this ok [y/d/N]: 
    

    However there are also older versions of foo and I want to ensure that at least a minimum of my new foo-2.0.0~a1-1.git.4871023.el7 package is installed, so I add a BuildRequires: foo-devel >= 2.0.0~a1 to bar.spec. But yum-builddep seems unable to handle that:

    $ sudo yum-builddep bar.spec 
    ...
    Getting requirements for bar.spec
     --> foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
     --> foo-devel-2.0.0a1-0.8.git.4871023.el7.x86_64
    --> Running transaction check
    ---> Package foo-devel.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
    --> Processing Dependency: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7 for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libfoo.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libfoo_hl.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libfoo_util.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    --> Processing Dependency: libna.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    ---> Package foo-devel.x86_64 0:2.0.0a1-0.8.git.4871023.el7 will be installed
    --> Processing Dependency: foo(x86-64) = 2.0.0a1-0.8.git.4871023.el7 for package: foo-devel-2.0.0a1-0.8.git.4871023.el7.x86_64
    --> Running transaction check
    ---> Package foo.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
    --> Processing Dependency: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7 for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
    ---> Package foo.x86_64 0:2.0.0a1-0.8.git.4871023.el7 will be installed
    --> Finished Dependency Resolution
    Error: Package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64 (foo)
               Requires: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7
               Available: foo-1.0.1-13.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 1.0.1-13.el7
               Available: foo-1.0.1-17.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 1.0.1-17.el7
               Available: foo-1.0.1-21.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 1.0.1-21.el7
               Available: foo-2.0.0~a1-1.git.4871023.el7.x86_64 (my_repo)
                   foo(x86-64) = 2.0.0~a1-1.git.4871023.el7
               Available: foo-2.0.0a1-0.2.git.c2c2628.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.2.git.c2c2628.el7
               Available: foo-2.0.0a1-0.3.git.c2c2628.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.3.git.c2c2628.el7
               Available: foo-2.0.0a1-0.4.git.5d0cd77.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.4.git.5d0cd77.el7
               Available: foo-2.0.0a1-0.5.git.ad5a3b3.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.5.git.ad5a3b3.el7
               Available: foo-2.0.0a1-0.6.git.299b06d.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.6.git.299b06d.el7
               Available: foo-2.0.0a1-0.7.git.41caa14.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.7.git.41caa14.el7
               Installing: foo-2.0.0a1-0.8.git.4871023.el7.x86_64 (my_other_repo)
                   foo(x86-64) = 2.0.0a1-0.8.git.4871023.el7
               Available: foo-1.0.1-9.el7.src (my_other_repo)
                   Not found
               Available: foo-1.0.1-12.el7.src (my_other_repo)
                   Not found
     You could try using --skip-broken to work around the problem
     You could try running: rpm -Va --nofiles --nodigest
    

    Is my understanding of being able to use:

    BuildRequires: foo-devel < 2.0.0a1
    BuildRequires: foo-devel >= 2.0.0~a1
    

    to enforce a version range not correct? I am sure I have seen this done and done this myself in the past.

    I even tried:

    BuildRequires: foo-devel < 2.0.0a1
    BuildRequires: foo-devel > 1.9
    

    to ensure it was not a problem with the pre-release version with the ~ in it.

    opened by brianjmurrell 3
  • Note for developers: Renew GPG keys for successful build

    Note for developers: Renew GPG keys for successful build

    The GPG key in https://github.com/rpm-software-management/yum/blob/master/test/gpg/key.pub expires, and the build will fail in make check stage.

    # gpg key.pub
    pub  2048R/D5865417 2017-07-26 Joe Doe <[email protected]>
    sub  2048R/2DB632D4 2017-07-26 [expires: 2019-07-26]
    

    As we known, the YUM is deprecated. Here is the fix:

    1. Go to test/gpg directory
    2. Generate a new set of GPG key to replace the key.pub, make sure it is in ascii
    3. Detach sign repomd.xml and generate a new signature repomd.xml.asc, make sure it is in ascii
    4. Replace the generated fingerprint and keyid in https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/test/pubringtests.py#L15-L16
    opened by gnought 0
  • Issue-121 fixes #121

    Issue-121 fixes #121

    Signed-off-by: Kevin J. Smith [email protected]

    I see that this is DEPRECATED. This fix can go to the real repo.

    closes #121

    opened by kevin-j-smith 1
The Fast Cross-Platform Package Manager

The Fast Cross-Platform Package Manager part of mamba-org Package Manager mamba Package Server quetz Package Builder boa mamba Mamba is a reimplementa

Mamba 2.3k Oct 24, 2021
An installation and dependency system for Python

Pyflow Simple is better than complex - The Zen of Python Pyflow streamlines working with Python projects and files. It's an easy-to-use CLI app with a

David O'Connor 904 Oct 19, 2021
A Poetry plugin for dynamically extracting the package version.

Poetry Version Plugin A Poetry plugin for dynamically extracting the package version. It can read the version from a file __init__.py with: # __init__

Sebastián Ramírez 148 Oct 9, 2021
Conan - The open-source C/C++ package manager

Conan Decentralized, open-source (MIT), C/C++ package manager. Homepage: https://conan.io/ Github: https://github.com/conan-io/conan Docs: https://doc

Conan.io 5.3k Oct 22, 2021
A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

Spack Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, a

Spack 2.3k Oct 15, 2021
A set of tools to keep your pinned Python dependencies fresh.

pip-tools = pip-compile + pip-sync A set of command line tools to help you keep your pip-based packages fresh, even when you've pinned them. You do pi

Jazzband 5.3k Oct 22, 2021
OS-agnostic, system-level binary package manager and ecosystem

Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for

Conda 4.3k Oct 23, 2021
OS-agnostic, system-level binary package manager and ecosystem

Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for

Conda 4.3k Oct 16, 2021
Install and Run Python Applications in Isolated Environments

pipx — Install and Run Python Applications in Isolated Environments Documentation: https://pipxproject.github.io/pipx/ Source Code: https://github.com

null 4.2k Oct 22, 2021
Python Development Workflow for Humans.

Pipenv: Python Development Workflow for Humans [ ~ Dependency Scanning by PyUp.io ~ ] Pipenv is a tool that aims to bring the best of all packaging wo

Python Packaging Authority 22.4k Oct 24, 2021
Python dependency management and packaging made easy.

Poetry: Dependency Management for Python Poetry helps you declare, manage and install dependencies of Python projects, ensuring you have the right sta

Poetry 16.8k Oct 24, 2021
Python dependency management and packaging made easy.

Poetry: Dependency Management for Python Poetry helps you declare, manage and install dependencies of Python projects, ensuring you have the right sta

Poetry 16.8k Oct 22, 2021
pip-run - dynamic dependency loader for Python

pip-run provides on-demand temporary package installation for a single interpreter run. It replaces this series of commands (or their Windows equivale

Jason R. Coombs 61 Oct 2, 2021
:package: :fire: Python project management. Manage packages: convert between formats, lock, install, resolve, isolate, test, build graph, show outdated, audit. Manage venvs, build package, bump version.

THE PROJECT IS ARCHIVED Forks: https://github.com/orsinium/forks DepHell -- project management for Python. Why it is better than all other tools: Form

DepHell 1.7k Oct 22, 2021
A PyPI mirror client according to PEP 381 http://www.python.org/dev/peps/pep-0381/

This is a PyPI mirror client according to PEP 381 + PEP 503 http://www.python.org/dev/peps/pep-0381/. bandersnatch >=4.0 supports Linux, MacOSX + Wind

Python Packaging Authority 263 Oct 17, 2021
The Python package installer

pip - The Python Package Installer pip is the package installer for Python. You can use pip to install packages from the Python Package Index and othe

Python Packaging Authority 7.5k Oct 23, 2021
A PyPI mirror client according to PEP 381 http://www.python.org/dev/peps/pep-0381/

This is a PyPI mirror client according to PEP 381 + PEP 503 http://www.python.org/dev/peps/pep-0381/. bandersnatch >=4.0 supports Linux, MacOSX + Wind

Python Packaging Authority 262 Oct 11, 2021
Solaris IPS: Image Packaging System

Solaris Image Packaging System Introduction The image packaging system (IPS) is a software delivery system with interaction with a network repository

Oracle 47 Sep 17, 2021
The Python Package Index

Warehouse Warehouse is the software that powers PyPI. See our development roadmap, documentation, and architectural overview. Getting Started You can

Python Packaging Authority 2.8k Oct 24, 2021