unfix SQLAlchemy version, to not conflict with latest CKAN

[florianm]

+1 (watching this PR with some urgency from my end) :-)

[amercader]

Can you elaborate a bit on this is an issue? Is because of a problem with a particular SQLAlchemy version or because it conflicts with the CKAN one?

[deniszgonjanin]

Yes, it's just a version conflict. ckan-service-provider doesn't need to be affixed to sqlalchemy 0.7.8, so it's better to let the version float. Otherwise it conflicts with newest ckan, as well as newer versions of spatial I think.

[florianm]

Can I raise the conflict of requests==2.5.0 as well? Many newer extensions are pinned to requests==2.7.0. E.g. ckan-galleries breaks on this. AFAIK requests==2.7.0 does some ssh handling differently, but nothing that impacts CKAN.

[amercader]

@florianm AFAICT ckan core has requests==2.3.0 pinned down so that is a separate issue I think

[florianm]

Fair enough, just out of interest, would unpinning requests introduce risk? Assuming that csp will always be installed next to a ckan with a moderately conservative requests version pinned. On 08/10/2015 9:12 pm, "Adrià Mercader" notifications@github.com wrote:

@florianm https://github.com/florianm AFAICT ckan core has requests==2.3.0 pinned down so that is a separate issue I think

— Reply to this email directly or view it on GitHub https://github.com/ckan/ckan-service-provider/pull/30#issuecomment-146539811 .

[davidread]

An easy change is to move these requirements out of setup.py into a requirements.txt, and then:

• newbies can have a pinned version, that avoids problems when new versions come out
• people that know what they are doing can mess with the version much more easily

[florianm]

This would also make the requirements turn up in http://rshiny.yes-we-ckan.org/ckan-pip-collisions/ which simple-mindedly only collects dependencies from requirements* files.

Streamlining and overriding requirements of ckan and all extensions would also be easier with a simple

grep -rl --include="*requirements*" 'requests' . | xargs sed -i 's/^.*requests.*$/requests==2.7.0/g'

[amercader]

+1 on using requirements.txt, which is the pattern we use everywhere else

[amercader]

But thinking about it that might affect the install process as ckan-service-provider is listed as a package from pypi on the requirements.txt of datapusher...

[florianm]

From my non-core-developer end, datacats is working again, I'm very happy to not touch things that currently work :-) ckan/ckanext-spatial#117 is far more important for me right now :-D On 09/10/2015 5:43 pm, "Adrià Mercader" notifications@github.com wrote:

But thinking about it that might affect the install process as ckan-service-provider is listed as a package from pypi on the requirements.txt of datapusher...

— Reply to this email directly or view it on GitHub https://github.com/ckan/ckan-service-provider/pull/30#issuecomment-146815488 .

[florianm]

Update, ckan core is now pinned to requests==2.7.0 On 09/10/2015 6:22 pm, "Florian May" florian.wendelin.mayer@gmail.com wrote:

From my non-core-developer end, datacats is working again, I'm very happy to not touch things that currently work :-) ckan/ckanext-spatial#117 is far more important for me right now :-D On 09/10/2015 5:43 pm, "Adrià Mercader" notifications@github.com wrote:

But thinking about it that might affect the install process as ckan-service-provider is listed as a package from pypi on the requirements.txt of datapusher...

— Reply to this email directly or view it on GitHub https://github.com/ckan/ckan-service-provider/pull/30#issuecomment-146815488 .