pypa / pipfile Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
Using requirements.txt
I can do it:
from pip.req import parse_requirements
requirements = [str(r.req) for r in
parse_requirements('requirements.txt', session=False)]
test_requirements = [str(r.req) for r in
parse_requirements('requirements-test.txt', session=False)]
How can I do the same using Pipfile?
Executable build descriptions are a bad idea. See https://www.reddit.com/r/Python/comments/5e2vci/pipfile_a_new_and_much_better_way_to_declare/da9c2ku/ or uncountable blog posts and articles all over the Internet for very good examples. It should be common knowledge by now, still the same errors are made again and again.
Pipfile has a nice hybrid approach in that it allows developers to generate a static Pipfile.lock
from a dynamic description. Tools can parse the static Pipfile.lock
and know exactly what to do, while developers can work with the more convenient Pipfile
and can be as smart or lazy as they want to. This approach might actually work very well.
For this to work, and for others like me to accept this idea, I thing the following point should be stressed out more: Tools work with Pipfile.lock
exclusively. A build system should never automatically execute a Pipfile
to generate a missing or outdated Pipfile.lock
. The pipfile
module should never be a build requirement.
Kind of like shards does. It's quite a bit more concise than TOML and even looks kind of Python-y.
I know the answer to this is probably going to be "big change, not enough gain", "conciseness isn't a good reason to switch", "harder to parse", etc...but I figured this still is worth a shot. ;)
Is there a good reason why Pipfile{,.lock}
couldn't be all lowercase? It sucks to have to hit the SHIFT-key when using the commandline, IMHO. At least, please consider accepting both pipfile
and Pipfile
.
There is no benefit in not including the extension (a sense of mystery?).
In fact you will only have things to gain (editor highlighting, etc).
ref: Initially opened here.
Perhaps you've already done this, but if not I'd suggest looking at how similar systems has solved issues around deterministic builds, dependency inconsistencies, the lock-file and similar. A non-exhaustive list:
If you have insights or tidbits from these projects, feel free to add them in the comments below.
Tools and IDEs cannot edit the Pipfile.lock
directly, because changes will be lost once the Pipfile
is executed again. Parsing and editing Pipfile
on the other hand is significantly more complicated that requirements.txt
. IDEs will most likely not support Pipfile
editing for a long time.
To put it in perspective: Pipfile.lock
is a read-only approach. Developers are forced to manually edit the Pipfile
with little to no tooling support in order do change the dependency settings of their project. This is a step backward compared to requirements.txt
or other static file approaches.
We already have so many files, a manifest, requirements files, config.cfg, tox, etc.
Let's remove the need for them and just have new sections in setup.cfg.
In addition #8, this is perhaps the most serious usability problem with the current approach: For a developer it is very easy to forget about Pipfile.lock
after editing Pipfile
, especially because he is not supposed to care about the lock file.
This is not an issue with pure approaches (setup.py
or requirements.txt
) because there is only one version of truth. Pipfile introduces an intermediate step that translates one truth into another, and different tools look at different files. This just asks for trouble. I can already see the broken builds and "fix: Forgot to build Pipfile" commits waiting to happen.
A very common workflow is to install a dependency manually, check if it works, and then add it to requirements.txt
or just call pip freeze
again. With Pidfiles, there is no pip freeze
(see #8) and you have to invoke a command-line utility after editing the Pidfile
to make things happen. Unfortunately, you just manually installed the dependency, so everything works anyway (on your computer) and there is no indication that your Pidfile.lock
is out of sync if you forget this step. You are a single git commit -a
away from a broken build.
Build or install tools (pip
) cannot check if Pipfile
and Pipfile.lock
are out of sync without executing the Pipfile
(which is bad, see #7) and cannot warn the user.
I've seen the example for using a git repository as an alternative source:
pinax = { git = 'git://github.com/pinax/pinax.git', ref = '1.4', editable = true }
What would the -e .
in requirements.txt equivalent be?
There have been a number of issues/comments that tend to trace back to a single question.. Should Pipfile
be executable or not?
The relevant comments are:
@defnull said in #8 (comment)
Parsing and editingPipfile
on the other hand is significantly more complicated thatrequirements.txt
. IDEs will most likely not supportPipfile
editing for a long time.
@jayfk said in #8 (comment)
On top of that, please don't forget server side tools working with dependencies (pyup.io, requires.io, etc.). There's no way to supportPipfile
s if they allow to run arbitrary Python code. Local developer tools might have a chance to establish a working solution over time, server side tools don't.
@defnull said in #9 (comment)
Build or install tools (pip) cannot check ifPipfile
andPipfile.lock
are out of sync without executing the Pipfile (which is bad, see #7) and cannot warn the user.
@defnull said in #7 (comment)
Executable build descriptions are a bad idea. See https://www.reddit.com/r/Python/comments/5e2vci/pipfile_a_new_and_much_better_way_to_declare/da9c2ku/ or uncountable blog posts and articles all over the Internet for very good examples. It should be common knowledge by now, still the same errors are made again and again.Pipfile has a nice hybrid approach in that it allows developers to generate a static
Pipfile.lock
from a dynamic description. Tools can parse the staticPipfile.lock
and know exactly what to do, while developers can work with the more convenientPipfile
and can be as smart or lazy as they want to. This approach might actually work very well.
For this to work, and for others like me to accept this idea, I thing the following point should be stressed out more: Tools work withPipfile.lock
exclusively. A build system should never automatically execute aPipfile
to generate a missing or outdatedPipfile.lock
. Thepipfile
module should never be a build requirement.
@takluyver said in #6 (comment)
I don't like specifying metadata in executable files in general. #8 gives one reason why not - it's very hard to reliably modify scripts programmatically.
There's also some reaction on https://www.reddit.com/r/Python/comments/5e2vci/pipfile_a_new_and_much_better_way_to_declare/
Since version 8, pip can now process requirements.txt files and check their hashes after download.
https://pip.pypa.io/en/stable/reference/pip_install/#hash-checking-mode
I think it would be a good idea to store those hashes in the generated .lock file
(A big inconvenience af the hash-checking mode of pip is that you have to specify the hash for every package and their dependencies, recursively ...)
Hi. I remember that we agree to do only default and dev group at this moment.
I want to explain my seeing of this feature if you decide to revisit this issue in the future.
We have customer who runs our web application written in python in its own cloud. Our application depends on few closed source packages developed for our customer by another team. We don't have access to this packages, but know provided api.
For testing purpose this team create stubs packages which we can install from PyPI installation running by our customer.
Before deploying new app release to staging infrastructure new code is reviewed by customer programmers team. In staging environment customer devops install real packages with known names from another PyPI instance running at customer staging environment. After QA engineers approved new release same installation shipped to the production environment where customer PyPI instance running on another url.
So it's good to have something that can handle this tricky setup easily. I see it like
[packages]
customer_package_foo = "*"
customer_package_bar = "*"
[packages:staging]
<<inherit packages from previous section>>
<<pin real dependencies of foo and bar packages>>
<<provide staging pypi url>>
[package:prod]
<<inherit packages from staging>>
<<provide prod pypi url>>
Is there a way to give a custom name for Pipfiles?
See here for context:
https://github.com/kennethreitz/pipenv/issues/248
In the npm
world, you can install new packages like so:
npm install --save <package>
and the --save
flag will write the package details to the package.json
(pipfile
equivalent). I feel this will be a neat inclusion for pip
/pipfile
I know this project was just open-sourced and is still under active development, so consider this a reminder to update the README with some additional info when the time is right.
Some questions that immediately popped into my mind, which others are likely to ask, include:
Pipfile
relate to setup.py
and the upcoming pyproject.toml
? Is it the same relationship as the one described here between requirements.txt
and setup.py
?setup.py
to pyproject.toml
transition, we seem to be moving away from using Python and more towards using a declarative syntax for specifying build system requirements. With this proposed requirements.txt
to Pipfile
transition, however, we seem to be moving in the opposite direction. Could you comment on this?Pipfile
just use a Python-like syntax, or will it actually run Python code, like setup.py
?Pipfile.lock
, and will packaging end-users need to care about this file?Hello.
I differential python library to "application". A library ends up typically on pypi to be used by another application. One should never do a pip install thislibrary
in production. Should comes from a pip install thisapplication
that consequently install other apps and libraries.
For me, application should indeed have frozen dependencies, to ensure perfect reproduction. But libraries deployed on pypi should better be using "range" for acceptable version. For exemple, if two libraries depends on frozen version of another lib (say 1.0
and 2.0
), there will be a conflict. Libraries dependencies are better described with range (I know my lib will work with this dependencies from version 1.0
to 3.0
, or require a version >1.1
, and so on).
Is it possible to do this with the pipfile and how? It is possible to describe this subtility in the documentation? "How to handle dependencies of a library or an application" ?
Thanks
Why there even needs to be one? In PHP (Composer) and JS (npm, yarn), there is only one file type and libraries and applications work OK with these — libraries just don't need to commit their lockfile.
There is a difference between an application and a library, but on the pip's end, it's just a bunch of dependencies with versions specified.
print 'No matching distribution found for pipfile' when use pip install pipfile
.
My tools version as below:
pip version: 9.0.1
python version: 2.7
pipdeptree style
pipdeptree==0.10.1
- pip [required: >=6.0.0, installed: 9.0.1]
Sphinx==1.6.2
- alabaster [required: >=0.7,<0.8, installed: 0.7.10]
- babel [required: !=2.0,>=1.3, installed: 2.4.0]
- pytz [required: >=0a, installed: 2017.2]
- docutils [required: >=0.11, installed: 0.13.1]
- imagesize [required: Any, installed: 0.7.1]
- Jinja2 [required: >=2.3, installed: 2.9.6]
- MarkupSafe [required: >=0.23, installed: 1.0]
- Pygments [required: >=2.0, installed: 2.2.0]
- requests [required: >=2.0.0, installed: 2.17.3]
- certifi [required: >=2017.4.17, installed: 2017.4.17]
- chardet [required: >=3.0.2,<3.1.0, installed: 3.0.3]
- idna [required: <2.6,>=2.5, installed: 2.5]
- urllib3 [required: >=1.21.1,<1.22, installed: 1.21.1]
- setuptools [required: Any, installed: 36.0.1]
- six [required: >=1.5, installed: 1.10.0]
- snowballstemmer [required: >=1.1, installed: 1.2.1]
- sphinxcontrib-websupport [required: Any, installed: 1.0.1]
is more friendly and explicit than
alabaster = "==0.7.10"
Babel = "==2.4.0"
certifi = "==2017.4.17"
chardet = "==3.0.3"
docutils = "==0.13.1"
idna = "==2.5"
imagesize = "==0.7.1"
Jinja2 = "==2.9.6"
MarkupSafe = "==1.0"
pipdeptree = "==0.10.1"
Pygments = "==2.2.0"
pytz = "==2017.2"
requests = "==2.17.3"
snowballstemmer = "==1.2.1"
Sphinx = "==1.6.2"
sphinxcontrib-websupport = "==1.0.1"
urllib3 = "==1.21.1"
I'm not saying copy the syntax, just the idea of showing which package installed / is dependent upon which package. It is nice.
find with max_depth=1 will fail even if pipfile is in the current directory. Is that intentional?
The API is currently designed in a way that it tightly coupled with the file system. The parse
function for example expects the Pipfile
to be a filename: https://github.com/pypa/pipfile/blob/master/pipfile/api.py#L70
It'd great if we could find a way to decouple the API from the filesystem, at least in parts. This won't work for functions like walk_up
, but when I look at parse
it'd relatively easy to just pass in a file like object:
def parse(self, file_handle):
# Open the Pipfile.
content = f.read()
...
Same goes for the find
function. Instead of calling os.getcwd
explicitly in find
, call it in walk_up
:
@staticmethod
def find(max_depth=3):
"""Returns the path of a Pipfile in parent directories."""
i = 0
for c, d, f in walk_up():
...
def walk_up(bottom):
"""mimic os.walk, but walk 'up' instead of down the directory tree.
From: https://gist.github.com/zdavkeos/1098474
"""
bottom = os.path.realpath(os.getcwd())
...
This would help external tools a lot to work with the API. There are probably still a lot of design decisions to make here, but if there's any interest in supporting external tools I'd be happy to submit a PR that addresses some of the points I mentioned earlier.
https://pipfile.pypa.io/ give me a DNS address could not be found
error.
Advantages:
--save
, --save-dev
, --save-exact
could be implemented without much effort
common file format, so we could use existing editor capabilities
In the future we possible could converge existing pyproject.toml
, setup.py
and this file, into one.
This is a little specs, I've created, maybe it will be of any use (it's not complete, VCS has to be expanded, maybe I've forgotten some other cases)
[dependencies]
# plain, command: pip install --save Django
django = ">=1.10.1"
# command: pip install --save-exact Django
django = "==1.10.1"
# command: pip install --save Django==1.10.1
# Any specified specifier goes exactly (even without --save-exact)
django2 = "==1.10.1"
# full version
SomeProject = {version = "==5.4"} # denotes what version exists as a part of package metadata
# environment markers
SomeProject2 = {version = "==5.4", markers = {python_version = "< 2.7", sys_platform = "win32"}}
# OR
[dependencies.SomeProject2.markers]
sys_version = "< 2.7"
sys_platform = "win32"
# particular file
# all non-obvious dependencies should be specified as a table (not inline), it's more verbose, which is a good thing here
[dependencies.numpy] # appears after --save
file = "./downloads/numpy-1.9.2-cp34-none-win32.whl"
# OR
numpy = {file = "./downloads/numpy-1.9.2-cp34-none-win32.whl"}
wxpython = {file = "http://wxpython.org/Phoenix/snapshot-builds/wxPython_Phoenix-3.0.3.dev1820+49a8884-cp34-none-win_amd64.whl"}
# per-requirement overrides
#FooProject >= 1.2 --global-option="--no-user-cfg" \
# --install-option="--prefix='/usr/local'" \
# --install-option="--no-compile"
# maps to
FooProject = {version = ">=1.2", setup_py_options = """--global-option="--no-user-cfg"
--install-option="--prefix='/usr/local'"
--install-option="--no-compile"""} # multiline string, only multiline that in valid in TOML
# OR
# if used in conjunction with --save (it's automatically generated, that's why doesn't really matter if it's verbose or not)
[dependencies.FooProject]
version = ">=1.2"
setup_py_options = """--global-option="--no-user-cfg"
--install-option="--prefix='/usr/local'"
--install-option="--no-compile"""
# if necessary to add hashes
# https://pip.pypa.io/en/stable/reference/pip_install/#hash-checking-mode
hashes = """ # maybe convert to array
--hash=sha256:2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 \
--hash=sha256:486ea46224d1bb4fb680f34f7c9ad96a8f24ec88be73ea8e5a6c65260e9cb8a7
"""
# VCS
flask = {git = "git repo", revision = "hash"}
# extras (dev, test, production), dev could be special-cased as [dev_dependencies]
[extras.PDF]
ReportLab = ">=1.2"
Hi, thanks for yet another awesome tool!
I wander if there is any plans to add commands abbreviations for example in scripts section.
So instead of typing each time pipenv run python -m unittest discover it will be enough to run pipenv test (or maybe pipenv apply test) if we have this in the Pipfile:
[[scripts]]
test = "python -m unittest discover"
Moved from https://github.com/kennethreitz/pipenv/issues/153
In the README, the develop
and default
are both JSON arrays, but in the Pipfile.lock
file in the examples
folder, they are objects. e.g.
"development": [
{"name": "nose", "version": "1.3.7", "hash": "..."},
]
"develop": {
"nose": {
"version": "==1.3.7",
"hash": "sha256:dadcddc0aefbf99eea214e0f1232b94f2fa9bd98fa8353711dacb112bfcbbb2a"
}
}
Should it be assumed that the one examples/Pipfile.lock
is the current spec since that's the generated format?
Also one is development
and the other is develop
.
Fresh install:
$ pipenv --version
pipenv, version 3.3.6
Simple Pipfile:
$ cat Pipfile
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
[packages]
crayons = { git="https://github.com/kennethreitz/crayons.git", ref="v0.1.2" }
Create lock file:
$ pipenv lock
Creating a virtualenv for this project...
[...]
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
... which generates this:
$ cat Pipfile.lock
{
"_meta": {
"hash": {
"sha256": "39b2447b7dd6976804de490321577a2db0f4fc4327e0795a93436ea69afad9a8"
},
"requires": {},
"sources": [
{
"verify_ssl": true,
"url": "https://pypi.python.org/simple"
}
]
},
"default": {
"crayons from git+https://github.com/kennethreitz/[email protected]#egg=crayons": {
"hash": "sha256:a292b7ef29131345fd329ff5a94d1e2e59569be4dbd9fa8b99ff7114d72102a6",
"version": "==0.1.2"
},
"colorama": {
"hash": "sha256:a4c0f5bc358a62849653471e309dcc991223cf86abafbec17cd8f41327279e89",
"version": "==0.3.7"
}
},
"develop": {}
}
And now installing breaks:
$ pipenv install
No package provided, installing all dependencies.
Pipfile found at /[...]/Pipfile. Considering this to be the project home.
Installing dependencies from Pipfile.lock...
An error occured while installing!
Invalid requirement: 'crayons from git+https://github.com/kennethreitz/[email protected]#egg=crayons==0.1.2'
It looks like a path. Does it exist ?
To activate this project's virtualenv, run the following:
$ pipenv shell
These are the versions in my env:
$ pip freeze
appdirs==1.4.0
blindspin==2.0.0
click==6.7
click-completion==0.2.1
colorama==0.3.7
crayons==0.1.2
delegator.py==0.0.8
Jinja2==2.9.5
MarkupSafe==0.23
packaging==16.8
parse==1.6.6
pew==0.1.26
pexpect==4.2.1
pipenv==3.3.6
pipfile==0.0.1
ptyprocess==0.5.1
pyparsing==2.1.10
pythonz-bd==1.11.4
requests==2.13.0
requirements-parser==0.1.0
resumable-urlretrieve==0.1.4
six==1.10.0
toml==0.9.2
virtualenv==15.1.0
virtualenv-clone==0.2.6
I've been looking for about 15 minutes now after discovering a Pipfile in a project I was looking at. I can't figure out how to use it. Maybe you could add a simple example usage to your readme?
Originally reported by @charettes:
Shouldn't implicit dependencies be included in the lock files as well à la
pip freeze
?
Reasoning for that is simple: imagine package A depends on B == 1.0
, and package B depends on C >= 1.0
. Then C 1.1 comes out with some subtle changes that break B completely, and — BAM! — your build is broken.
The problem with this is, PyPI doesn't return packages dependencies (I've tried several APIs, no luck), so in order to lock dependencies we need t actually install them first. Doesn't seem like a big deal to me, though.
Currently, pip install
outputs You must give at least one requirement to install (see "pip help install")
. It would be nice to be able to do just pip install
in a directory with a Pipfile.lock
and have it recognize and run the installation automatically based on that file. This behavior is identical to pip install -p
("when -p
is bare") as described in the README
but provides a default for pip install
without needing the -p
flag, like npm install
. If no Pipfile.lock
file is found, pip install
can output its current error message.
Additionally, perhaps pip install
can recognize a Pipfile
if there is no Pipfile.lock
file, run the install, and generate a corresponding Pipfile.lock
file.
Thoughts?
Bundler is an amazing tool in ruby-land.
I hope you guys study some of it, as it works really really well.
Specifically, A major pain point there was an addition of the specific "Bundler" version to the Gemfile.lock .
This was a painful migration, but later on allowed much more power to the Bundler authors, if it's in upgrades or in specific lock file changes.
I think if you add this and the specific bundler logic (only update when newer version exists) it will save much pain later on -
rubygems/bundler#3697
I recall a long discussion on #43 and elsewhere, where a decent consensus was reached to change to freeze files, so as to avoid confusion with file locking. I may be confused, but this seems to have been unilaterally reverted? I can't find any further discussion.
As we know, pip
installs packages globally, unlike npm
. Moreover, currently pip
does not even try to deal with dependency conflicts (when you need both packages A and B, and they both depend on different versions of package C) in any way. It doesn't even notify you much about the fact it has just broken your dependencies.
Classic example, taken from here:
We develop our project or library and we need splinter
and huxley
as the dependencies. So we gonna install them:
$ pip install splinter
Pip installs splinter==0.7.5
and selenium==3.0.2
as splinter's dependency
$ pip install huxley
Collecting huxley
...
Found existing installation: selenium 3.0.2
Uninstalling selenium-3.0.2:
Successfully uninstalled selenium-3.0.2
Successfully installed huxley-0.5 selenium-2.35.0
So we likely broke splinter
, and, moreover, Pip said that everything was successfull. It even trolled us by saying successfully uninstalled package-that-we-use
. And the user probably didn't notice anything, we don't read the logs line by line, when script ended successfully. It is bad.
Is it planned to define within this spec a behavior different from described above, when the packages with incompatible dependencies will be brought together in single Pipfile
?
lock
is most popular filename suffix for storing exact package versions. Maybe we should use Pipfile.lock
filename instead of Pipfile.freeze
? Am I missing something?
One of the concerns raised in previous discussions of this idea is that it risks inheriting all the problems that have historically plagued setup.py, such as having to execute arbitrary code just to extract project metadata.
Having Pipfile.lock
mitigates a large part of that problem (since the generated JSON metadata will already be static at install time), and a gemspec-style pyproject()
directive would make it straightforward to delegate to a library-style pyproject.toml
file when a given repo supports both direct deployment as a service and publication as a versioned component.
However, it would also be possible to explicitly discourage (but not entirely prevent) the inclusion of arbitrary control flow logic by blocking access to most of the builtins when executing Pipfile
code. For example:
>>> limited_namespace = dict(__builtins__={})
>>> exec("import sys", limited_namespace, {})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1, in <module>
ImportError: __import__ not found
This wouldn't provide a security boundary (sandboxing Python code isn't that simple), but it would mean that imports and the open()
command wouldn't work by default, and folks would have to actively work to gain access to the standard builtins in order to change that.
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).
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.Anyway, really looking forward to using this!
Thanks for listening
Mark
Does the pipfile manage the required C libraries and platform specific packages too?
If I understand correctly previous version of Pipfile was build around python like syntax and allows define arbitrary groups like that:
package('django')
with group('develop'):
package('django-debug-toolbar')
with group('test'):
package('pytest')
with group('develop', 'test'):
package('django-extensions')
And I could define any group I want and install it explicitly, correct?
How can I define similar pipfile with recent toml syntax?
Hello! Sorry for asking such a question as an issue, but search did not helped me about official position of this project.
Is this project considers to be an official replacement for pip's requirements.txt?
Will it be just another entry in [[source]]
with a boolean extra=True
?
Or pipfile will consider extra-index-url to be just like any other source? if so, anything that uses Pipfile will have to do some try/excepts to see if the current package is present in each of the listed sources (because some of them can be a extra, and contain just some specific listed packages)
Hello! When using pipenv i have an pipfile error: Double requirements given.
You can reproduce it with this Pipfile using a command pipenv install
.
I am not sure if it is pipenv or Pipfile's problem, so i decided to submit and issue here. As far as i know, many users are facing this problem.
I think using context managers for package grouping looks more elegant.
Also I like the idea of usingsource
as context manager from @dstufft's original proposal.
It should be possible to set dependencies by Python version to allow installing backported modules only when needed.
I learned about MetaPathFinder
class from importlib and created this hack:
http://lonetwin.github.io/blog/html/2016/05/16/auto_install_missing_python_modules.html
Since I discovered this hack, I have been thinking that something of an 'install-on-missing-import' feature would be, in theory, a possibility,
I've been wrestling with getting an implementation which works with requirements.txt for and in fact, I do have a rough implementation which parses the requirements.txt and installs the requirements at import time. This works for most simple installations, although I haven't tested it extensively.
I would like to suggest that maybe pipfile
could designed (and possibly provide a reference implementation) of a MetaPathFinder
which ensures that the developers and users of modules don't even have to worry about running a command to install anything. Just executing or importing the module should install the necessary dependencies.
This is just a suggestion and I'm ok if people think this idea is ridiculous. That said, knowing the reasons why such a thing would be ridiculous would be appreciated.
Is there support or planned support for installing packages before installation the current package (at build time), such as Cython or NumPy, as described in https://www.python.org/dev/peps/pep-0518/
Is there any converter?
Or any unified schema for starting to develop it?
#10 organically grew into a discussion on which format should be used in Pipfile
. Since that is a completely different question from whether Pipfile
should be executable, I think that it deserves a dedicated issue.
You can obviously see comments there for the (brief) history on this.
Rather than naming it "Pipfile.lock", could we call these something else before they catch on?
<something>.pipfile
. Lots of software (the mac's Finder, windows's Explorer, Nautilus, Vim, Emacs, Apache, Nginx, anything that knows how to read /etc/mime.types
) can infer a MIME type from an extension easily and only from a full filename with great difficulty if at all. Even if it's always called Pipfile.pipfile
, please consider a unique file extension..lock
is a file that you call flock()
on, or perhaps, over NFS, that you call open(..., O_CREAT | O_EXCL)
on. In other words, it is a lock. I realize that this naming convention is sort of by extension to Ruby's Gemfile.lock
, but (A) the contents of the file are of a different MIME type than Gemfile.lock
so it should be a different extension, and (B) Gemfile.lock
is one of the worst, most baffling names ever given to an abstraction. Other suggestions: KnownGood.pipfile
, ExactVersions.pipfile
, Complete.pipfile
, Exhaustive.pipfile
, Repeatable.pipfile
...?Don't get me wrong - this is extremely useful functionality and I'm looking forward to using it! I just really hope that we can avoid repeating a templated set of mistakes that many programming tools seem intent on promoting these days.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.