Why?
Show HN: FunctorFlow – An attempt to re-imagine Python libraries
51–55 of 55 posts
Re: Show HN: FunctorFlow – An attempt to re-imagine Python libraries
#52Earlier quoted context omitted.
"Lego blocks" "tech toys" "tinkering" "cool kids" "next big-thing" -- perhaps they are your hopes for this project, but these are all vague, filler words that don't tell me what this thing actually does. If I take a look at it what do I see? It's not until I get to the twitter account that I see that it looks like you're trying to create not just a different python package manager, but a new ecosystem that's not back…
https://twitter.com/functorflow/status/1157396077043167232
Not an issue I've dealt with during the last 10 years in production. On OSX, homebrew python + standard virtual environments + pip mitigates that completely. On the Ubuntu side, system python + standard virtual environments + pip work fine as well. Anything else?
Re: Show HN: FunctorFlow – An attempt to re-imagine Python libraries
#53Earlier quoted context omitted.
I'd actually implement it as a transparent venv and use pinned versions in a requirements.txt – with hashes, of course.
That'd make sense. You'd need to pin all transitive dependencies as well and cache the venv. Not sure if you'd need to find older versions of new direct dependencies to avoid conflicts. For example, you run the sheet in 2015 and then again in 2019 but with a new import. That new import's latest version has a transitive dependency that you already pinned but has different version requirements than what you pinned. I w…
> You'd need to pin all transitive dependencies as well and cache the venv.
I think to do this stuff, you need hooks in Jupyter to setup and teardown the venv before it runs the kernel. (And generally Jupyter would want to clean up unused venvs to mitigate the teardown hook not firing.)
> Only issue is that it'd be really space inefficient
A venv is overkill. You can just run the kernel in a regular directory, and `pip install --target kernel_dir foo-bar-pkg` to put packages directly in it. As long as the linker sees it, third-party libraries will work. This technique is used in the serverless project[1] to bundle dependencies for use on AWS Lambda.
> Not sure if you'd need to find older versions of new direct dependencies to avoid conflicts.
Curation is a solution to this. Stackage[1] is popular in the Haskell community; they build a consistent version set of everything every night and curate stable releases periodically.
With curation, a date and a set of top-level packages is enough to pin your dependencies.
[1]: https://github.com/commercialhaskell/stackage#frequently-ask... [2]: https://github.com/UnitedIncome/serverless-python-requiremen...
Re: Show HN: FunctorFlow – An attempt to re-imagine Python libraries
#54For those developers who wish to earn an extra income in their free time while helping MOOC students complete their MOOC courses consider registering as an expert tutor here: https://moocteas-stage-web.azurewebsites.net/
Helping others learn while rewarded for doing so.
Re: Show HN: FunctorFlow – An attempt to re-imagine Python libraries
#55Well, this has all the signs of well-meaning but inexperienced developers seeing a market opportunity without appreciating the many difficult problems that will have to be solved to produce something that is secure, reliable and interoperable with current development ecosystems.
Rather than abuse them, we might perhaps use them as an example of the Dunning-Kruger effect.