Charging for uploads and downloads? isn't that making the whole service inconvenient<p>It says 2000 monthly downloads. I will consume that in a single day with my automated CI pipeline. Is hard to take this into consideration.<p>Uploads and downloads makes sense to be unlimited. At least having bandwidth limits like any basic hosting service.
> Helpful<p>> Browse your packages and read their documentation just like on the public Python Package Index.<p>I don't remember the last time I read package information from pypi. It's all on Github or readthedocs or similar. And given that it isn't especially difficult to host your own index [0] or make docker images with all the dependencies pre-installed, I don't see how this justifies the price.<p>If it were available as an extension on Github or a self-hosted git server solution like GitLab, Gitea or Bitbucket, then that would be more interesting to me.<p>[0]: <a href="https://packaging.python.org/guides/hosting-your-own-index/" rel="nofollow">https://packaging.python.org/guides/hosting-your-own-index/</a>
For those looking to secure their systems from external source failures, I'd recommend taking a look at Sonatype's Nexus Repository [1]. It supports a wide range of package sources and has the option to self-host.<p>I almost didn't know that Github was down the other day because all the packages I was using were already cached on Nexus.<p>[1] <a href="https://www.sonatype.com/nexus-repository-software-component-management" rel="nofollow">https://www.sonatype.com/nexus-repository-software-component...</a>
I've used DevPi [1] in my previous job while my current team uses Artifactory [2] and both are pretty decent solutions while the latter of course is rather expensive.<p>Personally I've found DevPi to be more than sufficient for a small-medium team that can spare a little time to set it up and maintain it but PyDist's pricing plans would make it an attractive alternative (except for that download limit, that won't fly).<p>That being said I wonder how a service like this will fare once the GitHub Package Registry [3] becomes mainstream and introduces Python support.<p>[1] <a href="https://github.com/devpi/devpi" rel="nofollow">https://github.com/devpi/devpi</a>
[2] <a href="https://jfrog.com/artifactory/" rel="nofollow">https://jfrog.com/artifactory/</a>
[3] <a href="https://github.com/features/package-registry" rel="nofollow">https://github.com/features/package-registry</a>
No offense, but I'm getting to the point of hating free trials.<p>Why?<p>1. Because you're fixed in an arbitrary point of time, which means you have to focus on the free trial above other things, many of which might deliver higher value.<p>2. If you decide to not use it, it's wasted time. Like a design decision that you don't discover that's a showstopper 40 hours into the trial.<p>3. 14 days really isn't a good metric to decide if it's worth using your service or not. You may not see real issues until you get at least a month into the service.<p>4. Anyone who is seriously considering purchasing the service isn't going to bat an eye at the actual cost.
It says it mirrors PyPI. Does that mean I can use --index-url rather than --extra-index-url? The latter has some properties that make it less than ideal for private packages.
I 'like' how instead of <i>Pricing</i>, the link to the pricing is ambiguously titled <i>Plans</i>, as if it were a link to their project roadmap instead of a payed service.