Add sasmodels and sascalc to PyPI

[rozyczko]

Secondary aim is egg that can be shipped to pypi
from ticket #452

Migrated from http://trac.sasview.org/ticket/580

{
    "status": "new",
    "changetime": "2016-06-19T16:32:57",
    "_ts": "2016-06-19 16:32:57.602295+00:00",
    "description": "Secondary aim is egg that can be shipped to pypi\nfrom ticket #317",
    "reporter": "piotr",
    "cc": "",
    "resolution": "",
    "workpackage": "SasView Bug Fixing",
    "time": "2016-06-06T11:12:30",
    "component": "SasView",
    "summary": "Sasmodels egg to be shipped to pypi",
    "priority": "major",
    "keywords": "",
    "milestone": "SasView Next Release +1",
    "owner": "",
    "type": "defect"
}

[butlerpd]

Trac update at 2016/06/19 16:32:57:

• butler commented:

This should probably not be a 4.0 issue (i.e. can be done before or after). In fact it is almost an admin task? May move to admin in the future but move to +1 for now.

• butler changed milestone from "SasView 4.0.0" to "SasView Next Release +1"

[pkienzle]

Renaming ticket.

[pkienzle]

Standalone sasmodels usage with fitting requires data loaders, which are currently defined in sas/sascalc/dataloader. Can we move the data loaders to sasmodels or create a stand-alone sasdata package on pypi?

[llimeht]

Removing circularity between packages is a definite win. I too have been around the #467 block in trying to use sasmodels independently of sasview.

(In doing so, it would be nice to also find a better way of dealing with documentation building for SasView; the current situation of needing the sibling projects checked out, built, documentation built, all using a particular directory layout so that parts of that can be copied from one project to another is quite unusual and painful for CI, release builds, and downstreams.)

[pkienzle]

Looks like it is on pypi so closing this ticket. Sasdata is also on pypi so the circularity issue is resolved. Now all it needs is sasdata listed as a dependency, but that is a separate issue (literally: #529).