New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python packages that are pinned to a specific version can not be packaged as .deb #206

Merged
merged 7 commits into from Apr 13, 2012

Conversation

Projects
None yet
2 participants
@specialunderwear
Contributor

specialunderwear commented Apr 12, 2012

This is because python uses '==' but debian requires '='.

After I managed to fix that I noticed fpm turns '=' into a combination of '>=' and '<<'. Turns out that debian also supports '=' which is more accurate so I changed that in the second commit. Maybe you've got a specific reason to do this, in which case you can just use the first commit.

specialunderwear added some commits Apr 12, 2012

let pkg_resources do the parsing of the specs. When multiple specs ar…
…e found prefer order is "<=", "==", ">=" and next the version number.
According to http://www.debian.org/doc/debian-policy/ch-relationships…
….html#s-depsyntax (= version) is valid and also that is sematically more correct than (>= version) and (<< version+1) because your +1 guess is just that, a guess.
@@ -2,11 +2,23 @@
import json
import re
import time
import pkg_resources

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

What is the earliest version of python is pkg_resources available in? Having some trouble googling to find this.

This comment has been minimized.

@specialunderwear

specialunderwear Apr 12, 2012

Contributor

pkg_resources comes with setuptools, the package that gives you easy_install.

This comment has been minimized.

@specialunderwear

specialunderwear Apr 12, 2012

Contributor

And if you are making packages, you've got it installed.

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

woot, thanks for the details :)

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Apr 12, 2012

After I managed to fix that I noticed fpm turns '=' into a combination of '>=' and '<<'

fpm should not be doing this, I'll comment inline with the code.

@@ -254,20 +254,7 @@ def fix_dependency(dep)
# Convert gem ~> X.Y.Z to '>= X.Y.Z' and << X.Y+1.0
if dep =~ /\(~>/
name, version = dep.gsub(/[()~>]/, "").split(/ +/)[0..1]

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

Why remove support for the '~>' dependency operator? (Rubygems uses this)

This comment has been minimized.

@specialunderwear

specialunderwear Apr 12, 2012

Contributor

Sorry about that, ignorance from my side.

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

no worries, the code needs better documentation ;)

nextversion[l-1] = 0
nextversion = nextversion.join(".")
return ["#{name} (>= #{version})", "#{name} (<< #{nextversion})"]
elsif (m = dep.match(/(\S+)\s+\(= (.+)\)/))

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

I think this was to allow multiple iterations for the same version installed., so it's a needed feature, though perhaps not coded correctly.

The idea is taht if you have package version "1.2.3" you want to permit "1.2.3" <= version < "1.2.4" - this allows 'iteration' values in versions like "1.2.3-10"

This comment has been minimized.

@specialunderwear

specialunderwear Apr 12, 2012

Contributor

Ok but If I pin a package with '==' in my setup.py, I would never want to have 1.2.3-10 instead of 1.2.3. I guess I did break the ruby operator though, which seems to have such a meaning.

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

Well, look at it from "the debian world". You would release "version 1.2.3" of your python package. Debian maintainer pacakges it up as "python-specialunderwear version 1.2.3-1" the "1" is the 'package revision' or 'iteration' - essentially a meta version for the package. If there's a typo, said maintainer releases "python-specialunderwear version 1.2.3-2" which still points exactly at your version 1.2.3 but fixes a typo in the package process itself, not in your code. Thus, in debian's world, it is expected mostly that any "version 1.2.3-xxx" includes the same version (1.2.3) of the software, but simply has small fixes in packaging (dependency, description, etc) by the maintainer between package revisions.

Does this make sense? I think that's why this must be the default behavior.

However! What you are asking for is totally reasonable - I myself do not care about debian's practices.

So I propose the following - Add a new flag to fpm's deb package plugin that allows "exact versioning" as you are wanting here and would disable the current behavior. Would this be OK?

This comment has been minimized.

@specialunderwear

specialunderwear Apr 12, 2012

Contributor

Yeah that's cool! I'll add a patch to the pull request adding that.

This comment has been minimized.

@jordansissel

jordansissel Apr 12, 2012

Owner

Awesome! Thanks for helping with this :)

This comment has been minimized.

@specialunderwear

specialunderwear Apr 13, 2012

Contributor

I ended up using --deb-ignore-iteration-in-dependencies because it was already there (and used nowhere). Your documentation says: "(deb target only) For = dependencies, allow iterations on the specified version. Default is to be specific." so I left it at that. If you want the default behavior to be NOT specific like you say above. Well, then this is wrong ...

specialunderwear added some commits Apr 12, 2012

Use existing --deb-ignore-iteration-in-dependencies flag to determine…
… if dependencies should be strictly versioned or allow iteration.
Nolonger lose information whith compound specs.
When a compound spec is found, like tornado>=1.0,<=1.1 multiple entries will be
added to the dependency list:

tornado >= 1.0 and tornado <= 1.1

Because that seems to work for the debian dependency specification.
@specialunderwear

This comment has been minimized.

Owner

specialunderwear commented on 6f1cf01 Apr 12, 2012

I noticed debian has no problem with duplicate dependency definitions so now all version spec arguments are added separately. I wouldn't now how that works for other packaging systems ...

jordansissel added a commit that referenced this pull request Apr 13, 2012

Merge pull request #206 from specialunderwear/master
Python packages that are pinned to a specific version can not be packaged as .deb

@jordansissel jordansissel merged commit a518418 into jordansissel:master Apr 13, 2012

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Apr 13, 2012

Thanks for this :)

@specialunderwear

This comment has been minimized.

Contributor

specialunderwear commented Apr 18, 2012

Could you please submit a new version of fpm to the ruby gems repository? I need this fix ...

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Apr 25, 2012

fpm 0.4.7 with this patch released now!

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Apr 25, 2012

erm, 0.4.8, that is

prof-milki pushed a commit to prof-milki/xpm that referenced this pull request Dec 18, 2014

jls
Merge pull request jordansissel#206 from specialunderwear/master
Python packages that are pinned to a specific version can not be packaged as .deb

prof-milki pushed a commit to prof-milki/xpm that referenced this pull request Dec 27, 2014

Merge pull request jordansissel#206 from specialunderwear/master
Python packages that are pinned to a specific version can not be packaged as .deb

jordansissel added a commit that referenced this pull request Apr 24, 2015

Merge pull request #206 from specialunderwear/master
Python packages that are pinned to a specific version can not be packaged as .deb

jordansissel added a commit that referenced this pull request Jun 20, 2016

Merge pull request #206 from specialunderwear/master
Python packages that are pinned to a specific version can not be packaged as .deb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment