The justification was "Because Github et. al. support markdown, pypi
should too", presumably for the purpose of allowing one to write their
README once, and have it work in both places. This is already possible,
and only adds unneeded complexity to an already complex system. If you
want to ma
On 3 May 2016 4:19 PM, "Alexander Walters" wrote:
>
> I am -1 on this on the basis that the services mentioned also happily
support restructured text READMEs
I don't understand why that makes you say no to the ability to support
markdown.
Rob
___
Distu
I am -1 on this on the basis that the services mentioned also happily
support restructured text READMEs
On 5/2/2016 12:40, Nick Timkovich wrote:
Markdown READMEs are becoming increasingly ubiquitous for many
projects. GitHub, GitLab, Bitbucket, among others, happily detect .md
readme files and
Markdown READMEs are becoming increasingly ubiquitous for many projects.
GitHub, GitLab, Bitbucket, among others, happily detect .md readme files
and render them in their web interfaces. rST is nice, but is generally
overkill for single-page documents (as opposed to more intricate
documentation). T
Entry points are separate from the build and install systems bundled with
setuptools. Usually when we talk about replacing or deprecating setuptools
we mean first the install part, then the build part. Entry points are fine.
The core reason we want to use pip to install (including for development
On 2 May 2016 at 19:25, Thomas Güttler wrote:
>
>
> Am 02.05.2016 um 09:14 schrieb Noah Kantrowitz:
>>
>> The correct way to do that these days is `pip install -e .` AFAIK.
>> Setuptools should be considered an implementation detail of installs at
>> best, not really used directly anymore (though
Am 02.05.2016 um 09:14 schrieb Noah Kantrowitz:
The correct way to do that these days is `pip install -e .` AFAIK. Setuptools
should be considered an implementation detail of installs at best, not really
used directly anymore (though entry points are still used by some projects, so
this isn'
Hypothetically, the alternative is to break non-application entrypoints
(the ones NOT used for console scripts or gui applications) into some
other infrastructure. The people that use entrypoints for their plugin
systems might be given a build system agnostic option if that were the
case. Con
You make it sound like there's a plausible alternative to setuptools
entry points -- is there?
02.05.2016, 10:14, Noah Kantrowitz kirjoitti:
The correct way to do that these days is `pip install -e .` AFAIK. Setuptools
should be considered an implementation detail of installs at best, not real
The correct way to do that these days is `pip install -e .` AFAIK. Setuptools
should be considered an implementation detail of installs at best, not really
used directly anymore (though entry points are still used by some projects, so
this isn't really a strict dichotomy).
--Noah
> On May 2, 2
I was told this:
> `python setup.py develop` uses urllib2 to download distributions whereas pip
uses requests
Souce: http://stackoverflow.com/a/36958874/633961
This can create confusing situations and I want to avoid this.
Is there a way to use only **one** way to install python packages?
Do
11 matches
Mail list logo
