<div dir="ltr"><div><div>Hi Folks,<br>
    <br></div><div><i>I've been sitting on this draft for a couple of months, partly to think on it some more, but mostly as I didn't want to the lob a ball into play until I had the time to see it through. I've come to realize that a time-space for this idea wasn't going to magically open for it of it's own accord, so for better or worse, here it is... :)<br>

</i></div><div><i><br></i><br>
    Something I've been pondering for awhile but haven't fully
    investigated to see if it's feasible end to end: maybe we should move python packages
    from Osgeo4W to pypi (<a href="http://pypi.python.org/pypi" target="_blank">Python Package Index</a>).<br>
    <br>
    I've been relatively successful and installing a number of packages
    which aren't included in o4w using `pip install`,
    <a href="http://trac.osgeo.org/osgeo4w/wiki/ExternalPythonPackages" target="_blank">http://trac.osgeo.org/osgeo4w/wiki/ExternalPythonPackages</a>, which got
    me thinking that maybe we could or should publish most or all python
    packages this way.<br>
    <br>
    --- Advantages ---<br>
    <br>
     - reduces the number of packages we need to maintain<br>
    <br>
     - dev team can focus on producing a standard "build and publish to
    pypi" recipe instead of a multitude of "build and test and publish
    to o4w for pkg-xxxx" recipes and distribution packages (and historical versions).<br>
    <br>
     - opens available packages far beyond what we can do, potentially
    to the entire [Windows] python universe<br>
    <br>
     - pip (setuptools, distribute) dependency management resolution
    functions far outstrip what we have, and are actively worked on by
    many developers. It's smart.<br>
    <br>
    <br>
    --- Challenges ---<br>
     
    <br>
    - how will, or can, Setup.exe pass requests through to pip so the
    smooth graphical install experience is maintained? <br>
    <br>
     - pip dependency resolution doesn't work for non-pypi binaries, e.g. PyQt, and certainly not for binaries with
    specific version requirements. (So these packages will still need to
    be produced as they are now, so actually -0 rather than -1)<br>
    <br>
    - pip relies on packages built by setuptools and distribute, which were forked but are now in the
    long slow process of figuring out how to merge back into a single
    project. This will take some time, and in meanwhile, now, there is
    churn. On the other hand, it is on the track for official blessing.<br><br></div>best regards,<br><br></div>-matt wilkie<br></div>