Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If this project is dead, just tell us

github.com

Post reply on HN
Print view View original

301–310 of 325 posts

Re: If this project is dead, just tell us

#301

Post by jchiu1106 »

alecbenzer wrote: post #155
coleifer wrote: post #109

I see a lot of comments about "hey it's open-source, just fork". The reason people feel upset is because this project was shilled hard when it was released. The python packaging team was officially recommending it, stuff like that. There was some backlash because of legitimate usability concerns with the software, and what was perceived as the tacit blessing of a project solely due to the maintainer's having written…

> the maintainer's having written another popular project. Potentially relevant: https://vorpus.org/blog/why-im-not-collaborating-with-kennet...

Wow I didn't know it became that bad. He came across as an egostic person but I didn't know he's more than that...

Re: If this project is dead, just tell us

#302

Post by earthboundkid »

WilliamEdward wrote: post #65
mikkelam wrote: post #8

Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem

Just curious, you don't find learning entire languages hard or confusing but suddenly writing 3 commands to set up a venv is too 'messy'?

It's a pain in the ass when you have colleagues who only know JS or HTML/CSS or whatever and they need to install the project to run it on their machines, and you have to explain "virtual envs" and other bullshit that doesn't exist in sane packaging ecosystems to get them up and running.

Re: If this project is dead, just tell us

#303

Post by lainga »

dessant wrote: post #200
foob wrote: post #146

Earlier quoted context omitted.

I think that's the default for most high exposure projects. Unless, of course, both projects have the same author, and that author's primary concern is increasing their own exposure.

The cult of personality that is being nurtured around certain members of the Python community definitely harms the Python ecosystem, because solutions with glaring flaws get a pass when they are stamped with someone's name, and the mismanagement of projects is rarely addressed. Then there's also the issue of such members of the community exploiting the human tendency to worship others.

Do you think this is unique to the Python community? Any thoughts as to why it might be so?

Re: If this project is dead, just tell us

#304

Post by nwallin »

nitrogen wrote: post #300
cogman10 wrote: post #268

Earlier quoted context omitted.

Yup. Further, I do a lot more research in the dependencies I bring in (if I can help it). Does this thing also bring in 1000x sub dependencies? How much am I REALLY going to use this. What's the actual added value here. I've seen people bring in libraries for simply the dumbest things. The worst offender I've seen is lombok brought in for a @Logger annotation on one class. That stopped our java 6->8 migration because…

If you can write the used functionality in 10 minutes, you should not bring it in as a dependency. I disagree with this; it depends on the size of the dependency, plus the risk of a problem with the dependency vs the risk of making a mistake vs the risk of code drift when the same 10-min thing gets written a dozen different ways across an org.

I think you are dramatically underestimating the cost of a dependency.

The dependency may change in surprising ways in the future. The dependency may not change in expected ways in the future. (ie, now you're trapped in an old version of the language, or another one of your dependencies)

The problematic part with reinventing the wheel or NIH is that you add a fixed cost of doing business to any given change. The problem with importing the world is that you add a dynamic cost to simply existing without change.

It's a tradeoff, and it's not a tradeoff that's consistent across organizations. For some orgs it's really important to be first to market. In other orgs it's important to not break shit for your existing customers.

My org is well established in our field. Nothing matters more than retaining our existing customers. Importing a new lib requires approval from legal, which requires about a personweek. In other words, if one developer could implement the same thing in less than 40 hours, the developer should implement it themself. For us, a slow moving org, I think we're at the right place. For a startup, obviously not.

Re: If this project is dead, just tell us

#305

Post by wyclif »

dwaltrip wrote: post #196
yingw787 wrote: post #16

I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools

We also recently switched from Pipenv to pip-tools and so far it has been very pleasant. Our workflow: - Use pyenv to manage python versions (mostly works pretty well) - In the beginning, use builtin python 3 tooling to create virtual env for the project: "python3 -m venv venv" - Whenever needed, add new libs to "requirements.in" - Run the "pip-compile" command to generate a new "requirements.txt" with the dependency…

I also switched to using pyenv to manage versioning. So far it's been painless. You should never mess with the system Python if you're on a Mac.

Re: If this project is dead, just tell us

#306

Post by cerberusss »

xenator wrote: post #287
strunz wrote: post #210

Earlier quoted context omitted.

Can you link to one of these times a maintainer said something like that?

I put myself in very uncomfortable position. When I need to prove my words by blaming someone who did very good job for the community in general. At least have these good intentions. And the same time I don't want shame somebody in public. I did some research and think this link is enough https://github.com/pypa/pipenv/issues/1137 .

Wow... some users are subtly pressuring the maintainers into work here. The maintainer simply states "works as intended".

The users in that topic then continue the discussion in all of its aspects, expecting the maintainer to engage with them. I can imagine it feels to the maintainers as an energy-sucking discussion.

IMHO, you're not shaming the maintainers, you're shaming the community here.

Re: If this project is dead, just tell us

#307

Post by wyclif »

cik wrote: post #99
aequitas wrote: post #83

Earlier quoted context omitted.

I recently switched from Poetry (to which I switched after pipenv) to pip-tools for some projects, because Poetry was not able to work properly with some dependencies. Pip-tools has been a dream. It is just a thin layer of tools on top of Pip that separates your 'abstract' requirements (eg: django edit: it also automates updating the release requirements file (within the constraints of the abstract requirements).

Thanks for this. I've been a poetry fan since... the first release and pipenv really just fails for me. I'm going to check out pip-tools today.

I like that poetry uses pyproject.toml to replace setup.py, requirements.txt, setup.cfg, MANIFEST.in and the newly added Pipfile. Simplifying it to one file seems smart.

Re: If this project is dead, just tell us

#308

Post by acemarke »

dwaltrip wrote: post #196
yingw787 wrote: post #16

I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools

We also recently switched from Pipenv to pip-tools and so far it has been very pleasant. Our workflow: - Use pyenv to manage python versions (mostly works pretty well) - In the beginning, use builtin python 3 tooling to create virtual env for the project: "python3 -m venv venv" - Whenever needed, add new libs to "requirements.in" - Run the "pip-compile" command to generate a new "requirements.txt" with the dependency…

The `pip-tools` portion of that is basically what I came up with myself and described in another thread at https://news.ycombinator.com/item?id=21779929 , except that I'm trying to use `pythonloc` to install things in a local `__pypackages__` folder per PEP-582 instead of using venvs.

Re: If this project is dead, just tell us

#309

Post by Too »

teddyh wrote: post #299
MadWombat wrote: post #289

Earlier quoted context omitted.

> but I think this is confusing something painful with something useful There is software out there that absolutely cannot break. Like "if this breaks, people will die". Medical software, power plant software, air traffic control software, these are obvious examples, but even trading and finance software falls into this category, if some hedge fund somewhere goes bankrupt because of a software bug real people suffer.…

> I am not working on anything like this. I work on a lighting automation system. If I fuck up my release, nobody is going to die (well, most likely, there are some scenarios), but if I fuck up sufficiently, a lot of people will be incredibly annoyed. So I have every version of every dependency frozen. All the way down the dependency tree. Most people’s systems are not that special that they absolutely need to do thi…

This is the danger of living on the edge of EoL, as you called it. Once you are forced to update a packages, usually with short notice at the most inconvenient time ever due to some zero-day vulnerability found in one of your depdendencies. Then the new version no longer supports another old version it has a subdependency to, which you also pinned, so you have to update the subdependency also. And to upgrade that package you have to update yet another subdependency, and so on.

Suddenly a small security-patch forces you to essentially replace your whole stack. If your test flags any error you have no idea which of the updated subpackages that caused it, because you have replaced all of them. Eventually you accumulate so much tech debt that it's tempting to cherry-pick the security patches into your packages instead of updating them to mainline, sucking you even deeper down the tech debt trap.

Integrating often means each integration is smaller, less risky and easier to pinpoint why the failure happens. Of course this assumes you have good automatic test coverage, which i assume you do if the systems are as life-critical as parent claim them to be.

There's also a big difference between embedded and connected systems here. Embedded SW usually get flashed once and then just do whatever they are supposed to do. Such SW really is "done", there is no need to maintain it or it's dependencies because it's not connected to the internet so zero-days or other vulnerabilities are not really a thing.

Post reply on HN