@ -8,38 +8,6 @@ This project is useful if you have private Python packages in GitHub that you wa
*Note:* You can use `-e git+ssh://git@github.com/<owner>/<repo>@<tag>` with `pip` to install private packages using git.
However, if you needed to allow someone without ssh access to GitHub the ability to install your package, or make private packages installable from a location that does not have ssh access to GitHub (e.g. docker container) then this server will make that easier for you.
## GitHub repo requirements
### Project structure
PyPIHub will not validate the source files of your package, however, you should structure the package as though you would publish them to [PyPI](https://pypi.org).
This means that your package should contain a `setup.py` file and be installable (you can use `python setup.py install` or `python setup.py develop` to test).
### Releases
PyPIHub expects that you use tags in your repo to denote releases.
If you use [GitHub releases](https://github.com/blog/1547-release-your-software) for your repo, then only those releases will be used by PyPIHub.
However, if you do not use GitHub releases, then all git tags will be used as versions.
### Version names
It is recommended (but not required) that you use [Semantic Versioning](http://semver.org/) of your projects.
*Note:* PyPIHub will automatically strip any leading `v` from your version/tag name. This will turn `v1.0.0` into `1.0.0`, which is more `pip` friendly.
### Assets
PyPIHub will always try to make a `.tar.gz` source asset available for installing from either your release or tag.
However, it is recommended that create a release and build/upload the assets for your package.
See [Creating releases](https://github.com/blog/1547-release-your-software#creating-releases) for more information.
To build assets, you can use `python setup.py sdist bdist_wheel` which will create a `.tar.gz` and a `.whl` file into a `./dist` directory.
Both of these files can and should be attached to the release.
PyPIHub will not validate the source files of your package, however, you should structure the package as though you would publish them to [PyPI](https://pypi.org).
This means that your package should contain a `setup.py` file and be installable (you can use `python setup.py install` or `python setup.py develop` to test).
### Releases
PyPIHub expects that you use tags in your repo to denote releases.
If you use [GitHub releases](https://github.com/blog/1547-release-your-software) for your repo, then only those releases will be used by PyPIHub.
However, if you do not use GitHub releases, then all git tags will be used as versions.
### Version names
It is recommended (but not required) that you use [Semantic Versioning](http://semver.org/) of your projects.
*Note:* PyPIHub will automatically strip any leading `v` from your version/tag name. This will turn `v1.0.0` into `1.0.0`, which is more `pip` friendly.
### Assets
PyPIHub will always try to make a `.tar.gz` source asset available for installing from either your release or tag.
However, it is recommended that create a release and build/upload the assets for your package.
See [Creating releases](https://github.com/blog/1547-release-your-software#creating-releases) for more information.
To build assets, you can use `python setup.py sdist bdist_wheel` which will create a `.tar.gz` and a `.whl` file into a `./dist` directory.
Both of these files can and should be attached to the release.
## Differences with other projects
PyPIHub differs from other projects, like [devpi](http://doc.devpi.net/latest/) in that it doesn't try to be a fully functioning replica of [PyPI](https://pypi.org/).
PyPIHub does not support creating users, uploading packages, or even mirroring PyPI. Is meant purely as a `pip` compatible proxy for packages stored in GitHub repos.
## Security
PyPIHub does not offer any security/authentication methods. This means that anyone who has access to make HTTP requests to the server will be able to access all source files for the proxied projects.
This implementation is by design. PyPIHub is meant to act as an unauthenticated proxy for private python packages for local development/testing.
