By splitting it into two different packages you end up with the same situation
that currently plagues psycopg2/psycopg2-binary whereby if you depend on
psycopg2 you can't easily swap in psycopg2-binary and vice-versa as the two
don't satisfy the same dependency.
Number 3 is kind of what sqlalch
Isn't your data folder mentioned here in your setup.py?
> On Jun 25, 2020, at 12:12, Stuart McGraw wrote:
>
> package_data={'mypackage': ['data/*.csv', 'tmpl/*.jinja',]},
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
htt
The package contains two files, and basically prints out:
"You probably meant to install flask-migrate"
It is meant to make sure that no-one else squats on the name and uses it to
exploit unsuspecting users that install the wrong package.
Bert JW Regeer
> On Mar 21, 2020, at 01
The package contains two files, and basically prints out:
"You probably meant to install flask-migrate"
It is meant to make sure that no-one else squats on the name and uses it to
exploit unsuspecting users that install the wrong package.
Bert JW Regeer
> On Mar 21, 2020, at 01
The nice thing with the new macaroons is that theoretically I can provide
someone my key to upload packages on my behalf for a singular PyPI project.
This way I could allow a third-party service to backfill binary wheels for
other platforms once I've released a version to PyPI.
Bert
> On Aug 2
Hey all,
I am not at the sprints and I am not sure where I can follow the discussion and
or see what people are coming up with.
Is there any feedback or information on editable installs using PEP517/PEP518
projects?
Bert
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe
> On Apr 6, 2019, at 23:10, Nathaniel Smith wrote:
>
> On Sat, Apr 6, 2019 at 2:14 PM Bert JW Regeer wrote:
>>
>> Hey all,
>>
>> You may have seen some hub hub around psycopg2 and no longer shipping binary
>> wheels by default [1][2] (and in
Is there a contact for the list owner so that people like this can get removed?
> Begin forwarded message:
>
> From: eys...@python-org.link
> Subject: Re: [Distutils] psycopg2/psycopg2-binary
> Date: April 6, 2019 at 15:34:29 MDT
> To: xiste...@0x58.com
>
>
>
>
>
Hey all,
You may have seen some hub hub around psycopg2 and no longer shipping binary
wheels by default [1][2] (and in fact using psycopg2-binary if you want
wheels), and I wanted to bring it up here because it demonstrates a problem
area with the current state of packaging in Python:
There is
> On Jan 4, 2019, at 12:36, Nick Coghlan wrote:
>
> On Fri, 4 Jan 2019 at 16:50, Nick Coghlan wrote:
>>
>> On Thu, 3 Jan 2019 at 11:13, Bert JW Regeer wrote:
>>> Is there some way to influence the egg info for the build when using pip
>>> whe
t@ourpatchset#egg=somerepo&egg_info=
https://github.com/org/somerepo.git@ourpatchset#egg=somerepo&egg_info=>"-b
+local"
Or is there a better method for dealing with this scenario?
Thanks,
Bert JW Regeer--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe
> On Sep 20, 2018, at 12:42, Donald Stufft wrote:
>
>
>
>> On Sep 20, 2018, at 2:29 PM, Bert JW Regeer > <mailto:xiste...@0x58.com>> wrote:
>>
>> pip not seeing any improvements is something I think will be sad. I don't
>> use pipenv,
; :p (This is intentionally rhetoric to touch on the
> we-should-use-pyproject-for-this camp. To be clear: I am not in that camp,
> that’s likely a bad idea unless we rethink the whole application-library
> distinction Python packaging makes.)
>
>
>
> TP
>
>
has re-iterated that view.
Don't contact me again.
>
> Dan Ryan // pipenv maintainer
> gh: @techalchemy
>
> On Sep 20, 2018, at 2:29 PM, Bert JW Regeer <mailto:xiste...@0x58.com>> wrote:
>
>>
>>
>>> On Sep 20, 2018, at 12:11,
> On Sep 20, 2018, at 12:11, Tzu-ping Chung wrote:
>
>
> On 21 Sep 2018, at 02:01, Bert JW Regeer <mailto:xiste...@0x58.com>> wrote:
>
>>
>>
>>> On Sep 19, 2018, at 23:22, Chris Jerdonek >> <mailto:chris.jerdo...@gmail.com>> wrot
> On Sep 19, 2018, at 23:22, Chris Jerdonek wrote:
>
> Thus, it's looking like things could be on track to split the user and
> maintainer base in two, with pip bearing the legacy burden and perhaps not
> seeing the improvements. Are we okay with that future?
This'll be a sad day. pip is sti
Speaking as a maintainer of various different packages for the Pylons project,
we include the following in our sdists:
- source code for the package
- tests for the package
- documentation for the package
and of course the license/history/changelog/everything you'd theoretically need
to create
17 matches
Mail list logo