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

Function names in files #4

Closed
mlakewood opened this issue Nov 20, 2016 · 6 comments
Closed

Function names in files #4

mlakewood opened this issue Nov 20, 2016 · 6 comments

Comments

@mlakewood
Copy link

First off, I'd like to say THIS IS GREAT!

Im really excited about having a better version of requirements.txt. I wasn't sure where the best place for suggestions on this project are, so I figured an issue at this early stage was a good place. As always this is just my initial thoughts, do what you will with them (that includes closing this issue).

  1. The dist() name doesn't make a whole lot of sense to me. I suspect its supposed to be short for distribution. My suggestion would be to make it about what the user wants to do. ie install, depends, require . These are all names that are in similar use in other package managers and I think make more sense. But names are also hard.
  2. I know a lot of confusion comes from what setup.py is for and what requirements.txt is for. It would probably be really helpful to have some guidance on that, and where this fits in there.
  3. I heard cargo from rust as a nifty feature called features. It allows a package to declare features that you could enable and you would get a set of transitive dependencies. So Django could have a postgres feature that you could opt into. When you do the psycopg2 package would get installed. If you don't then you only get sqlite. This allows the Django package owner to specify which version of postgres is installed while not making the user install the world. This would probably require a bunch of changes to setup.py/everything-else, but having a list of features that you could enable in this API might pave the way for that.

Anyway, really looking forward to using this!

Thanks for listening

Mark

@kennethreitz
Copy link
Contributor

Dist doesn't make sense to me either. I plan to call it package personally.

@kennethreitz
Copy link
Contributor

I have updated the README to reflect package, which I think is the best name.

@reillysiemens
Copy link

@mlakewood: FWIW, the features option you mentioned is reminiscent of the extras_require argument to setuptools.setup. Unless I'm mistaken that's what used to enable the notebook portion of IPython (you could install it with pip install ipython or pip install ipython[notebook]). Having a similar functionality in Pipfiles would be great, IMHO.

@reillysiemens
Copy link

Oh... Is that the intention with this syntax?

with group('development'):
    package('nose')

@mlakewood
Copy link
Author

Well if we could do the features with the extras_require that would be great.

I guess you could use the group syntax to control that. Its pretty arbitrary. But I think the features syntax is more about the next level down, ie allowing library maintainers to declare thier dependencies. At that level it might be groups but it seems to me that this file is more application dependencies rather than library dependencies. See other comments about where does this fit it?

@pradyunsg
Copy link
Member

Not relevant since #47

@dstufft dstufft closed this as completed Jan 26, 2017
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

5 participants