Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get indexes from pyproject.toml #671

Open
z3dev opened this issue Jan 23, 2024 · 3 comments
Open

Get indexes from pyproject.toml #671

z3dev opened this issue Jan 23, 2024 · 3 comments

Comments

@z3dev
Copy link

z3dev commented Jan 23, 2024

Hate to say this but the tools for installing and publishing packages are still not in sync. Flit has taken the project management to a nice level, and the commands are simple and understandable. But why does it stop there and still rely upon the old pip configurations in .pypirc for publishing? Why not including the indexes/repository configurations in pyproject.toml?

I know.. I know... it's a PEP thing probably. But why?

@takluyver
Copy link
Member

It's not particularly a PEP thing or a pip thing. .pypirc comes from distutils, I think, and now it's also used by twine. 😉

IMO, repository config makes more sense outside a project than inside. I use the same configured repositories for many packages, and sometimes publish the same package to different repositories (not necessarily at the same time). So the config gives me an alias for a particular index URL & username, and then Flit looks for a matching password/token in keyring.

The .pypirc config might not be how we'd design it now, but it's been good enough that there's not much pressure to redesign it. And the upside of that is consistency. You like Flit & pyproject.toml 🙂 but plenty of people are still confused by all the new options and standards for packaging, and want us to stop changing everything. So I doubt people will rush to replace another thing.

@z3dev
Copy link
Author

z3dev commented Jan 24, 2024

@takluyver thanks for the feedback, but I'm here to convince you that just a few more small changes can make flit even more useful for more people.

basically, we have lots of developers working across different hardware and OS platforms. this makes the configuration of each project even more critical. we want repeatable build results, no matter who does the development.

so, we are working out some issues with the projects on Windows. so far so good because the tools we have tested are pipenv and flit. now, developers only need to know two tools, including commands, options, nuances, etc.

i won't discuss the pains of getting things working. let's just say using Google Artifactory isn't documented well yet.

so, somewhere in the past the decision was made to support publishing of packages. not sure why filt took the extra step but the functionality is very nice. there's a nice configuration standard and documentation. but i have a few thoughts...

#1 dot file (.pypirc)

Basically, dot files are really evil for developers. There's no reason to hide configurations of development tools.

also, flit doesn't allow a different name even though the --pypirc option exists. Why always .pypirc ?

#2 more integration

flit has already extended the toml configuration, so why not extend further to support another section for the indexes. this would centralize the project configuration. of course, optional.

pipenv integration would also be nice. pipenv has the Pipfile defined, and there are 'source' sections for the artifactories. maybe flit could grab configurations from Pipfile. there are also dependencies defined as well. integration would be cool.

@z3dev
Copy link
Author

z3dev commented Jan 24, 2024

By the way, I saw the discussion about flit install. Basically, this is really nice functionality. It's a better alternative then searching documentation and learning pip options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants